Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».
Кто-то освежит память, кто-то сверится как с чек-листом, а кто-то заинтересуется и прочтет книгу. Т.к. пост получился достаточно объемным, можно добавить его в закладки и периодически к нему возвращаться.
Читать полностью »
От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.
Три дня и три ночи мастер не появлялся из своей кельи. На четвертый день монахи отправили послушника проведать его.
Мастер был занят созерцанием диаграммы потоков данных. Послушник узнал в ней второстепенную деталь обширной системы, поддержкой которой занимались монахи. Поклонившись, послушник поинтересовался, над чем работает мастер.
Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»
Читать полностью »
Две недели назад на Хабре публиковался перевод «Заблуждения программистов о времени», который по своей структуре и стилю основан на этом классическом тексте Патрика Макензи, опубликованном два года назад. Поскольку заметка о времени была крайне благоприятно воспринята аудиторией, то, очевидно, имеет смысл перевести и исходную статью об именах и фамилиях.
Джон Грэхем-Камминг (John Graham-Cumming) сегодня жаловался в своём блоге, что компьютерная система, с которой он работал, не приняла его фамилию из-за недопустимых символов. Конечно, там нет недопустимых символов, потому что любой способ, как человек представляет себя, — по определению — является подходящим идентификатором. Джон выразил сильную досаду насчёт данной ситуации, и он имеет полное право, потому что имя — суть нашей индивидуальности, практически по определению.
Читать полностью »
Недавно (буквально два года назад) тут пробегала статья Только 10% программистов способны написать двоичный поиск. Двоичный поиск — это классический алгоритм поиска. Мало того, это еще чрезвычайно простой алгоритм, который можно очень легко описать: берем отсортированный массив, смотрим в середину, если не нашли там число, в зависимости от того, что в середине — ищем это число этим же методом либо в левой части, либо в правой, откидывая средний элемент. Для функций также, просто берем не массив, а функцию. Все очень и очень просто, алгоритм описан почти везде, все баги словлены и описаны.
Так вот, я не могу реализовать двоичный поиск. Для меня он ни капельки не тривиален. Наверное, я ненастоящий программист. А ведь так и есть, я всего-лишь студент, но ведь это не оправдание? Если точнее, я не могу реализовать хороший корректный красивый двоичный поиск. Все время у меня вылезает проблема либо с корректностью, либо с красивостью, либо и с тем, и с другим. Так что, да, заголовок немного желтоват.
Прежде чем читать этот топик, напишите свою версию бинарного поиска — для отсортированного массива. Причем, в зависимости от параметра, поиск должен выдавать или первый элемент, или любой из дублирующих. Еще для сравнения, напишите бинарный поиск для функций
За последние пару лет я потратил много времени на дебаггинг чужих тестов. Это была интересная работа, иногда расстраивающая, но всегда поучительная. Кто-то может подумать, что в тестах нет багов, но конечно баги есть везде, и тесты не исключение.
Я постоянно удивлялся, как много ошибок в коде и тестов, и приложений происходят от неверного понимания и заблуждений насчёт времени. Под этим я имею в виду и компьютерный способ обработки времени, и фундаментальные ошибки, происходящие от несовершенной структуры календаря — зимнее время тут лишь вершина айсберга.
На самом деле, я повидал так много заблуждений, которые оставляют след в чужих (и моих собственных) программах, что посчитал полезным составить список самых частых проблем.
Читать полностью »
Доброго времени суток Дорогие читатели !
Вчера был опубликован, казалось бы банальный опрос на тему: «Много ли Хабражителей служили в армии? „.
Если быть честным, то я (офигел) был поражен с каким рвением пост набирал количество комментариев, которые не были однотипными.Читать полностью »
Первая попытка получилась немного сумбурна, поэтому я решил написать более последовательно.
Повторим основную идею: работу с базой нужно организовать через специально заточенный класс, а не разбрасывать код вызовов по всему проекту.
Но этому может препятствовать то, какой интерфейс предлагают производители баз данных. Мы потренируемся на базе MongoDB.
Здесь я предложу реализацию следующей логики работы:
Должен быть базовый класс, от которого наследуются все классы, которые будем сохранять в базе, пусть это будет DBData. Тогда у него будут просто 3 метода: Load, Save, Delete. А обращение к базе уже будет делом DBData.
Польза от такой концепции должна быть очевидна — пользователь объектов может не думая о реализации и нюансах баз данных просто сохранять и восстанавливать свои объекты. Но на этом пути есть ряд сложностей. Рассмотрим их.
Предисловие
В моем первом посте на Хабре завязался такой диалог:
A. важно, что к базе нельзя обращаться прямо, только через хранимые-процедуры, а за вызов хранимой процедуры ответственен определенный класс
B. «только через хранимые-процедуры» — что же вы NoSQL-продуктам скажете?
Дальше акцент сместился SQL vs. NoSQL. Но были потеряны основы: работу с базой нужно организовать через специально заточенный класс, а не разбрасывать код вызовов по всему проекту.
Я по прежнему считаю, что NoSQL — это слишком молодые продукты, чтобы они могли конкурировать с реляционными базами на полном серьезе. Но у NoSQL и несколько другая ниша. Мне понадобилось некоторое сохранение данных в проекте, где нет больших объемов. И поэтому я решил попробовать MongoDB. (я бы лучше поработал бы с Oracle NoSQL Database, но не нашел как с этим работать на C#).
Ну в общем все достаточно хорошо, чтобы сохранить объект в базе, оказалось надо сделать совсем мало:
var collection = db.GetCollection();
collection.Save(argObject);
где StrategiesData — тип моего объекта, argObject — собственно мой объект. Но такой стиль поощряет раскидывать как раз обращение к базе по всему проекту. Мешает явное указание типа вида . Ну, что остается отображение. Об этом и поговорим.
Хотел бы начать тему о недостатках декларативного подхода с простого примера – процедуры валидации.
Во многих системах (в большинстве?) валидаторы различных бизнес-объектов задаются в декларативном стиле – в виде атрибутов, XML конфигураций и др. Иногда валидаторы генерируются автоматически на основе структуры базы данных (длинны колонок например) и т.д.
Насколько оправдан декларативный подход когда мы задаем валидацию, насколько он удобен? Я предлагаю рассмотреть сложный случай, когда разрабатывается, например, B2Bсистема и каждый клиент, подключенный к системе, может в некоторых случаях иметь разные настройки валидации. Кроме того, предположим, что разработка ведется в команде в параллельных бранчах и нам нужно периодически объединять (merge) их. Да, и еще система предполагает локализацию валидационных сообщений.
Читать полностью »
Посмотрев конференцию GoingNative 2012 решил попытаться описать «best practice» для написания программ в стиле C++11. Планируется цикл статей, кому интересно, auto articlesIterator = articles.begin();
Читать полностью »
