Хм... Интересная заметка в комментах: http://voiceoftheworld.livejournal.com/326688.html Вот насчет черно-белых младенцев интересно. Потому как за 8 лет работы в IT (на штаты в основном) я видел с той стороны практически весь melting pot. WASPы, славяне, азиаты, семиты, латиносы, индусы (тысячи их), непальцы с сикхами. За все это время мне попался один афроамериканец (был еще один вполне черный чувак, но он был из Судана). На дворе вроде не 60-е, чтобы включать волынку про неравные возможности и расизм нанимателей. Неравные возможности паренька из Бангладеш и паренька из самого-самого худшего гарлемского гетто вообще не сравнимы, а расизм в данном случае должен быть слишком избирательным. Опять же, если взять страны третьего мира, то условия в Индии\Пакистане\Бангладеш мало отличаются от какого-нить Камеруна. Где волны набигающих программистов за еду из Африки? Непонятно.

Высокие технологии - это круто, но иногда "низкие" бывают на порядок полезнее и экономичнее, главное - мозгами шевелить в нужном направлении. Сейчас вы узнаете историю фабрики по производству зубной пасты, где возникла проблема обнаружения пустых тюбиков на выходе конвейера. Осознавая всю важность вопроса, директор фабрики созвал начальников отделов. Собрание постановило запустить новый проект - привлечь для решения проблемы пустых тюбиков стороннюю инжиниринговую компанию, так как собственный конструкторский отдел был слишком загружен, чтобы взять на себя дополнительную задачу. Проект включал закономерные стадии: ассигнование бюджета, запрос предложений на заключение контракта, привлечение независимой третьей фирмы к выбору подрядчика - и, 6 месяцев (а также 8 миллионов долларов) спустя, фабрика получила фантастическое решение - вовремя, в рамках бюджета, высококачественное и удовлетворившее всех. Это были высокотехнологичные прецизионные весы. В случае детектирования ими тюбика, который весил меньше, чем стандартный (т.е. был пуст), включалась сирена и сопровождающая импульсная световая иллюминация, конвейер останавливался, один из рабочих должен был дойти до конца ленты, снять бракованный тюбик, и запустить линию вновь. Некоторое время спустя, директор решил удостовериться в рентабельности проекта и, собственно, окупаемости инвестиций: результаты были поразительны - с момента установки весов с конвейера предприятия не сошло ни одного пустого тюбика, поступила всего пара жалоб от покупателей, а доля рынка продукции фабрики возросла. Однако, просматривая статистические данные, директор заметил, что количество дефектов, регистрируемых весами, снизилось до нуля через 3 недели после их установки и так и оставалось на том же нулевом уровне по сей день. Но ведь изначально обнаруживалась, по крайней мере, дюжина пустых тюбиков ежедневно. Это могло означать лишь одно - отчет неверен. Директор приказал поместить рядом с весами записывающее устройство, и после некоторого расследования, инженеры сообщили, что предоставленные сведения абсолютно достоверны. Весы действительно не регистрировали дефектов, потому что все тюбики, доходившие до них, были полными. Озадаченный, директор поехал на фабрику, решив взглянуть на весы самостоятельно. И что же он обнаружил?... За несколько метров до весов рядом с лентой конвейера стоял обычный офисный вентилятор за 20 долларов и сдувал пустые тюбики в корзину. «А, это один из рабочих поставил, потому что ему надоело ходить в конец линии каждый раз, когда звучала сирена» - объяснил директору пробегавший мимо сотрудник. Можно сделать вывод, что крайне трудно найти простое решение, изначально руководствуясь сложной замысловатой схемой его поиска, или что стимул в виде небольшого поощрения для обычных рабочих, которые как никто знают технологический процесс - ключ к возможному решению многих частных производственных задач. В любом случае эта история - яркая иллюстрация того, что следует мыслить проще при любой возможности.

[12:12:53] <Пиздос> чет нам всем в отделе раздали свеженькие книжки, а читать лень [12:13:22] <Пиздос> A Practioner's Guide to Software Test Design выглядит интересно [12:13:25] <Пиздос> но потом [12:13:28] <Пиздос> после обеда мб [12:13:49] <rkfg> A Practioner's Guide to Procrastination [12:13:57] <rkfg> Выглядит интересно, но читать лень [12:14:01] <rkfg> Потом почитаешь

Вопрос по гиту. Вот есть рефы. refs/heads/.., refs/remotes/../.. . Они заставляют гит не собирать мусорщиком коммиты, на которые они указывают, ну и дальше по графу. А могу ли я сделать (пусть и через низкоуровневые команды) какой-нибудь реф вида refs/mycommit, указывающий на нужный коммит, так, чтобы 1. ничего не наебнулось (все команды продолжали работать как раньше), 2. нужный коммит не был собран мусорщиком? Мне нужна не ветка, а именно реф, невидимый в `git branch -a`, недоступный для нормальной работы с ним, но предотвращающий потерю нужного коммита. (подразумеваю, что мне понадобится `git for-each-ref` для его поиска и что-то типа `git show` для его чтения, но это норм.) Нагуглить не смог, хотя и пытался, потому спрашиваю. И, пожалуйста, не надо про рефлог.

Вопрос к гитолюбам. Допустим, мы с Иваном Ильичём работаем на дизеле, а остальные коллеги что-то делают на мастере. Я локально ребейзю дизель поверх мастера, долго ебусь с конфликтами при этом. Иван Ильич, ничего не подозревая, доделывает свой кусок работы, пушит в дизель свои коммиты, затем уходит в запой на две недели. И тут я кончил ребейз, и что мне надо сделать, чтобы опубликовать новый вариант ветки "дизель"? git push origin diesel --force. Собственно вопрос: где окажутся коммиты Ивана Ильича после моих действий?

MLSSH (реализация ssh клиента и сервера) на окамле: http://dmzlj.livejournal.com/185158.html (с использованием пары dsl, насколько я понял). Что удивительно -- никаких упоминаний по существу гуглом не ищется, и всего ~ 2k упоминаний этого слова. Ещё удивительнее -- "Возможно, вы имели в виду: VK". Включаем паранойю!

А объясните мне, почему тупой трекер контента при клонировании репки клонирует только master branch? Какая там философия? Или, как обычно, никакой, ведь репка это всего лишь граф из рефов и блобов? (в кои-то веки понадобилось иметь именно гит-репку, причём не из-за того, что hg-git не работает или криво работает.) // не надо мне рассказывать, как склонировать в этом уёбище какие-то другие ветки: я умею пользоваться поисковиками для добычи знаний такого рода, но на вопрос "почему именно так?" они мне не ответили.

Я видел разные способы хранить интервалы дат в реляционках. Не, понятно, там два столбца, типа dt_start + dt_end, но кое-какие моменты не доходят до людей вообще. Попробую исправить. - null как дата начала/окончания -- неудобно. Правильное решение: фиксированные даты типа 01.01.0001 и 31.12.9999 и функции/вьюхи для получения видимой пользователем даты (если такая будет). Это только выглядит криво, а на самом деле спасает от тонн ошибок, связанных с нуллами. - главное: дата начала -- включительно, дата окончания -- исключительно. То есть, если есть дата начала 2014-12-07 00:00:00 и дата окончания 2014-12-08 00:00:00, в этот интервал попадают все даты 2014-12-07 XX:XX:XX, но не попадают 2014-12-08 00:00:00 и больше неё. С такими раскладами не получится сделать where mydate between dt_start and dt_end (если бы обе даты были "включительно"), но это абсолютно похуй, так как профит перевешивает: 1. условия не зависят от типов и форматов дат: в случае преобразования даты+времени в дату (если часы были 00:00:00) либо преобразования даты в дату+время (когда добавляют часы 00:00:00 к дате без часов) код продолжает работать как и раньше (а такие преобразования не всегда видны в коде невооружённым глазом, неявные преобразования типов таки случаются). 2. нет привязки к тому, какой "квант времени" подразумевался. Если бы интервал из примера выше был записан "концы включительно, квант = сутки", было бы "2014-12-07 .. 2014-12-07". Если бы надо было разбивать на часы, интервал внезапно преобразился бы в "2014-12-07 00:00:00 .. 2014-12-07 23:00:00". 3. часто надо рассмотреть "какие интервалы попадают на данную дату-время". В случае "квант = сутки" имеем where trunc(dt, 'DD') between dt_start and dt_end, заметьте функцию для обрезания даты и явное указание, докуда обрезать. А функции, как известно, не очень хорошо сотрудничают с оптимизатором запросов. - следствие обоих пунктов: валидация становится не сложнее, чем check (dt_start < dt_end) (для непустых интервалов) или check (dt_start <= dt_end) (для возможно пустых интервалов). - для извращенцев: with recursive либо connect by по условию prev.dt_end = next.dt_start

https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.4 -- постгрес хорошо движется вперёд, мне нравится.

"full stack web developer" -- эвфемизм для "биэндер".

Хоть вы меня за яйца подвесьте, но в сетевых протоколах² самое сложное -- грамотное завершение соединения, а в хранилищах данных -- грамотное восстановление после падения¹. Остальное -- выполнение собственно задач протокола/хранилища и обеспечение корректности завершения/восстановления -- поровну. ¹ -- интересно, есть ли глубокое философское объяснение подобной "дуальности" (завершение соединения vs начало работы с хранилищем). ² -- кроме udp.

3-way merge понадобился, стало лень .rej руками разгребать. Погуглил, первый попавшийся kdiff3 поставил. И он как-то криво мержит своей автоматикой -- там, где считает, что прав, переставляет куски кода, каменты куда-то в жопу лепит; в общем, сосёт. Вручную, на конфликтах, результат корректный, только гуй кривоватый (курсор иногда не там рисуется относительно места вставки печатаемых символов). Поэтому интересно, кто чем делает 3-way merge? Если не влом, манул какой-нибудь подкиньте, но и названия тоже ок. Или, если я заведомо криво настроил kdiff3, подскажите, что ему дёрнуть, чтобы он лучше лишний раз спросил меня, вместо того, чтобы хуйню выдавать как результат слияния.