> tfw кто-то какнул и не смывает хотя ты его учил, а ты стоишь под дверью весь тревожный

Как известно, способов написать программу существуют тысячи, а способов написать программу качественно — не более одного. Но зачем ее писать качественно? Ведь это удорожает разработку, при этом не приносит никаких очевидных профитов. Наоборот, это даже вредно для компании, потому что: а) на рынке выигрывает тот, кто быстрее выпустит первую версию, а не тот, у кого багов меньше или архитектура продуманнее; б) чем качественнее ПО, тем меньше затраты на его поддержку, тем меньше компания получает финансирования, тем выше вероятность сокращения штатов. Более того, поддержание качества ПО требует наличия квалифицированных кадров, которые редки и весьма недёшевы. Вывод: наиболее верная кадровая политика для софтверной компании — это найм максимально дешевых и наименее квалифицированных программистов («Цикл написать сможете? Ветвления? Вы приняты! Знаете инкапсуляцию, полиморфизм, наследование? Мы вам перезвоним!»). А мне как специалисту рекомендуется писать монолитный и максимально запутанный код. Все правильно? P. S. Весь этот хайп вокруг качества ПО, вокруг всяких «Code Complete», «Программист-прагматик», культ Agile и Unit Tests, а также ненависть к быдлокодерам, к забагованности софта поддерживается людьми для того, чтобы извлечь максимум выгоды из программиста за счет его личных интересов; подобно тому как школьная пропаганда общественных ценностей: «малышей не обижать», «с детства дружбой дорожить», «и воспитанными быть», любовь, доброта, честность, вот это все — предназначена для того, чтобы в будущем человека было проще эксплуатировать.

>Минус-факторы >- отсутствие фотографии в резюме или ссылки на соц. сесть с фотками (фото уха или другой части тела не прокатит) >- слабые коммуникации (боязнь людей, телефонных переговоров и т.п.) https://spb.hh.ru/vacancy/15601328

злитий блеклист програмістів: https://docs.google.com/spreadsheets/d/1YQv2E839DEqJ-bq5C872rpPVx-1RIh3XXjGAbcrE5kk/edit#gid=0

Какой тип у Y-комбинатора? Я знаю, что Y-комбинатор можно выразить так: Y g = g (Y g). Так вот, Y : ?

Какая относительная погрешность у double?

Современное IT: любая шутка или троллинг на тему заведомо нелепого решения оказывается чьим-то продакшеном.

Для тех, кому интересно - консерва ещё дышит. Заложил в неё несколько чанов на случай войны. http://bittext.ch/raw/?ID=_MhiklxwCp

Хм... Интересная заметка в комментах: 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. Собственно вопрос: где окажутся коммиты Ивана Ильича после моих действий?