Никогда не признавал подход БЛ в БД. Спорить на эту тему не хочу, но есть вопрос: а как в противном лагере справляются с такой задачей: нужно без down time добавить not null поле. В случае с БЛ в отдельном звене понятно как: вначале добавляем nullable поле, потом выкатываем сервис, который пишет данные в поле, затем скриптом дозаписываем данные где их нет, потом ставим на поле not null и выкатываем сервис, который читает поле. А что делают наши маленькие любители хранимок?

Нужно запустить flask под NGinx. Сейчас приглянулся uwsgi. Посоветуйте хороший способ (fpaws3, gunicorn, etc?).

Весь день в круг ломятся какие-то левые типы. У вас такого нету? Началось сегодня. Рекламщики нашли дешевый способ распространения рекламы?

Ищу статьи/книги на сабжевую тему. Нужно будет писать что-то вроде биллинга. Хочется заботать матчасть прежде. В первую очередь интересует представление денег и типовые схемы БД ну и подводные камни.

Я привык при программировании «вслушиваться» в код, анализируя его с точки зрения понятности и логичности. Хороший код в моем понимании как складный рассказ. Поэтому многие вещи я делают интуитивно.

Недавно пришлось спорить с одним товарищем на тему интерфейсов. Я как бы понимаю интуитивно, но аргументировано отстоять свою позицию не получается.

Суть спора в следующем: товарищ сторонник того, что бы на каждый класс клепать интерфейс. Я в общем-то интуитивно понимаю, что это действие когда-то имеет смысл, а когда-то нет. Проблема в том, что когда какой-то код не имеет смысла, то он как бы незаконно занимает место и только напрасно засоряет проект. Поэтому все же стоит различать когда надо, а когда нет и не делать «на всякий случай».

Попытался для себя составить список когда интерфейс нужен:

1. Есть несколько реализаций. Самый очевидный случай.
2. Реализация одна, но как бы подразумевается, что может быть несколько.

Есть еще такая штука: сегодня реализация одна, а завтра станет несколько. Но я считаю, что это не повод засорять код, рефакторинг «выделение интерфейса» - очень простой.

Больше не придумал. С моей точки зрения во всех остальных случаях класс вполне способен жить сам по себе.

Новость на опеннете

Для Ъ: компания LexisNexis собирается открыть исходники коммерческого аналога Hadoop - HPCC (High Performance Computing Cluster)

Некоторые последние споры на ЛОР вызвали у меня мозговую деятельность.

Как известно, применимость науки в разных дисциплинах разная. Вот я попытался составить цепочку, в которой применимость математики все меньше и меньше:

Физика, Проектирование электронной аппаратуры, Программирование, Экономика, Менеджмент.

Уважаемый ЛОР, чем же обусловлена такая закономерность?

ЗЫ. Варианты «там адепты все тупее и тупее» не рассматриваются.

ЗЗЫ. Блин, активизации мозговой деятельность не хватило что бы написать при чем тут Development. Читая про менеджмент и экономику у меня появилось стойкое ощущение, что там одни и те же проблемы, что и в программировании (не точно, не повторяемо и так далее).

Как-то слышал такое высказывание «X обладает свойством Y, это верно по построению». Звучит убедительно. Но как-то в скудном университетском курсе математики не припомню такого способа доказательства. Вообще такой способ доказательства имеет что либо общее с наукой или где?

Подобно тому, как некогда открытое и казавшееся вредным аэродинамическое сопротивление позволило людям летать, баги в коде позволили нам иметь те прекрасные весьма насыщенные возможностями программы, которыми мы имеем счастье каждый день пользоваться.

С воскресеньем тебя, ЛОР!

Для простоты будет считать, что есть целое число из диапазона [0, a]. Можно ли получить случайное число из диапазона [0, b] простым домножением на b / a? (Конечно, b <= a, иначе энтропии недостаточно) Как правильно округлять в таком случае до целого?

Кто-нибудь применял верификацию на практике? Нашел вот такую штуку: http://www.overturetool.org/ ЛОР, поделись опытом.

Кто ходит конференции, поделитесь какой в них смысл? Я сколько раз был ну может разок было интересно и то потому, что нашел себе собеседников пообщаться в перерывах. А сами доклады делятся в основном на 2 категории: тема тебе интересна и ты уже знаешь о чем примерно будут рассказывать (гуглить умеют все), либо тема не интересна вовсе. И общаться вообще мало с кем на конференциях, публика в основном состоит из хомячков. Может я не на те конференции хожу?

Если проанализировать развитие индустрии ПО, то можно сделать некоторые заметки: индустрия развивалась и развивается очень быстро; железо тоже очень быстро развивается, вместе с тем дешевеет.

Кроме того, развитие индустрии ПО происходит под влиянием некоторых особенностей: собственно изготовление программного продукта происходит задаром - компилятором. Доставка программных продуктов так же происходит практически бесплатно, интернет нынче дешевый.

Технологии находятся на очень высоком уровне. При таких благоприятных условиях, описанных выше, удалось автоматизировать почти всю рутину. Не последнюю роль в совершенствовании технологий имеет open source. В открытом доступе имеется огромное количество свободных библиотек и инструментов. Языки программирования сейчас имеют очень высокий уровень.

Раньше, когда все было не так радужно, когда компьютеры были слабенькими, библиотек мало ну и так далее, процесс кодирования был трудоемок и вполне было оправдано разделение труда программистов. Часть из них были собственно программистами и используя более высокоуровневую, по сравнению с используемыми в кодировании инструментами, нотацию писали спецификации для кодеров, которые преодолевали сложности написания кода и реализовывали спецификацию. Конечно, подразумевается, что работа их рутинная, следовательно требования к работникам-кодерам меньше чем к работникам-программистам.

В современном мире, мире высокоуровневых языков и мощных аппаратных платформ я не вижу места для кодеров, их труд уже автоматизирован с помощью компиляторов и библиотек. Да, существуют какие-то области, где дело обстоит иначе. Но если смотреть широко, на рутинные потребности бизнеса, ситуация мне видится именно такой. Кстати, коль потребность в прослойке-кодере отпала, отпала и потребность в языках спецификаций... Да-да, я про UML и тому подобное.

Есть еще одно наблюдение, связаное с предыдущим: технологии пошли вперед, а люди остались те же. Потребность в низкоквалифицированных кодерах отпала, а профессия программиста стала еще более популярной. Что из этого получается, догадаться не сложно.

Что по данной теме думает ЛОР?

Посмотрел 5-й форсаж из всего фильма больше всего запомнилась музыка. Стало интересно на каком языке сабж. Кажется, что на славянском каком-то, но википедия говорит, что автор бразилец.

Нужно сделать индекс для KV хранилища. Где можно почитать теорию?

Green threads я имею ввиду те, что в ерланге.

Предположим есть задача: приложение в процессе обработки запроса делает удаленный вызов, например к базе данных. Как я понимаю, в ерланге мы запустим процесс «запросить из БД», который при получении данных отправит их родительскому сообщению. Умная VM все распараллелит, используя гибридные треды. Есть другое решение - использовать корутины питона (по сути кооперативная многозадачность или я ошибаюсь?) и неблокирующий ввод-вывод. Кто кого в этом случае?

Еще я так понимаю неблокирующий ввод-ввывод можно и в ерланге замутить. Какая там будет модель обработки запроса?

Вобщем хочется пофилосовствовать на тему оптимальной стратегии ассинхронной обработки IO-операций.

Кто работал? Какие есть подводные камни? Как оно по производительности?

Нужно рисовать архитектуру распределенных систем: ноды кластера, балансеры, серверы бд, кешей и т.п. Какую тулзу порекомендуете?

Что там сейчас кошерно - webpy или cherrypy или еще что? Что я жду от него:

* Живой проект.
* Легкое наращивание возможностей путем подключения сторонних либ. Например что бы можно было прикрутить какой-нибудь шаблонизатор.
* Стабильность.
* В свое время мне очень понравился Sinatra, который на руби. Короче ищу что-то похожее.

Что буду писать: маленький сайт с «ручным» написанием sql. Можете отговорить меня в сторну джанги, но как-то оно слишком уж наворочено.

Слышал, что любую операцию можно сделать идемпотентной каким-то магическим преобразованием модели. Типа изменения «пристыковываются» к модели. Может кто-нибудь расказать по-подробнее?

Контекст: обычное приложение, что-то дергающее из базы данных

Цель: откзаться от использования транзакций.