​​У владельцев продуктов есть одна общая проблема, которую мы между собой называем «боязнь релиза». Она есть абсолютно у всех, исключений не бывает. Всё просто — если вам вдруг кажется, что вы всё доделали и продукт достаточно стабилен и хорош, чтобы показывать его окружающим, то вы безнадёжно опоздали. Напротив же, ежели кажется, что продукт сырой, то боязнь релиза быть обязана.

Ещё, конечно, боязнь релиза может отсутствовать, когда на продукт в целом плевать.

Так, ребята, у кого всё ещё хорошее настроение? Предлагаю его испортить, заполнив форму по ссылке ниже. Не для слабонервных. Я предупредил.

https://userinyerface.com/game.html

«Культура нации/сообщества сохраняет свой опыт преимущественно в форме своих национальных неврозов и табу.

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

Сельский житель в некотором смысле подобен кошерному еврею, для которого существует список не столько запретной еды, сколько разрешённой. На коллективной памяти его и соседских семей никто не умирал от довольно небольшой линейки грибов (порой всего пяти-шести видов), поэтому они привыкли поколениями уносить из лесу только их.

Горожанин, прочитавший в интернетах, как отличить зелёную сыроежку или шампиньон от бледной поганки — может самонадеянно притащить домой целое лукошко. Селянин нет. Налицо культурное различие в подходе к процессу: горожанин, рассматривающий сбор грибов как вид спорта, испытывает охотничий азарт. Селянин же, как существо вынужденно практичное, считает главным тот факт, что он точно не притащит домой бледную поганку.

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

- Темнее чего? - спросит ехидный селянин. И пояснит, что с грибами на самом деле всё сложно, что пресловутые кольца у поганок часто облезают и их не видно, что цвет пластинок — штука субъективная и что вообще лучше не лезть туда, где нет чётких и стопроцентных признаков.

Может быть, он, властно отобрав у горожанина корзинку и высыпав половину около станции, просто лишит его хорошего омлета. А может быть, спасёт ему жизнь.»

#dimoneverything из интернетов

​​Если вы собираетесь выполнять проект за один присест, у вас всегда будут проблемы. Лучшее, что можно с ним сделать — это разделить его на 6 этапов, и сложить их в отделы. А когда вы распределите его на 6 этапов, вот тогда можно просить предоплату. Только не надо прятать проект в дальний ящик, чтобы начальника не напугать. А вообще я слышал, что лучший способ - это скормить работу фрилансерам. Фрилансеров надо несколько дней не кормить, а после этого они возьмутся за проект за милую душу. Но для того, чтобы заказ хорошо выполнялся, надо сперва получить ТЗ и скоординировать правки. Конечно, этим можно заняться и потом, но кому охота потом править работу из чистого альтруизма? А проект они выполнят без проблем. Для того, чтобы за раз избавиться от одного задания надо как минимум 16 субподрядчиков, по-этому остерегайтесь владельцев фиктивных компаний. Тендер стоимостью в 20 тысяч фрилансеры сожрут примерно дней за восемь. Это значит, что один фрилансер пишет около 2 строк кода в минуту. Именно отсюда происходит присловие — «выгоревший, как Фрилансер».

Никто не знает какая сингулярность нас ждет. Возможно, человечество никогда не придумает исскусственный интеллект, а просто возьмет количеством фонннеймановского кода. Вполне вероятно, что те абстракции, что сейчас не позволяют подняться на следующую ступень программирования и оперировать сложными макро-командами возьмут верх над квантовыми вычислениями и тщетными попытками смоделировать мозг. Сейчас проходит соревнования роботов, в котором роботам-участникам предлагается много чего такого делать, чего ждут все фантасты. И по скромной оценке экспертов, модели роботов на этом конкурсе года имеют интеллект примерно трехлетнего ребёнка. Да-да, вы ничего не перепутали. Трехлетнего. И, конечно же, такое сравнение просто-напросто спекуляция. Они, конечно, делают все действия, на уровне ребенка, но их интеллект не сравним ни с одним живым существом, потому как они не имеют возможности обучаться и адаптироваться. Тем не менее, одно из возможных сингулярностей будет состоять из множества тьюринг-полных конечных автоматов. Хотя, как представить себе саморазвивающийся конечный автомат понятия не имею.

#перечитываяэкстраполяцию

Удивительно, насколько важную роль в формировании мнения отыгрывают стереотипы. И иногда они возникают по причине того, что желаемое выдаётся за действительное.

Недавно вспоминали Эйнштейна, с его прекрасным «Сделай настолько просто, насколько это возможно, но не проще». Это абсурдное по своему смыслу высказывание обычно используют тогда, когда хочется указать на повышенную сложность решения. Типа «Проще можно было, нафига ты усложняешь? Вон, Эйнштейна послушай». Абсурдное оно потому, что намеренного усложнения просто ради самого усложнения никто и никогда не делает. Если вдруг встречается что-то, что с первого взгляда кажется чересчур сложным, то логично предположить, что ты что-то недопонял, раньше требования были другие или кто-то чего-то не знал, когда писал. И да, автор переусложнённого куска делал его настолько просто, насколько это казалось ему возможным и ни в коем случае не проще.

А ещё цитата немного неверная. Наверное ошибка в переводе появилась. В оригинале он говорил «Всё следует упрощать до тех пор, пока это возможно, но не более того», что есть просто пересказанной Бритвой Оккама.

К слову, Бритву Оккама тоже многие неверно используют. Лайк и репост, если хочешь продолжения рубрики #экстрастереотипы

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

Этим экспериментом мы пытались подтвердить (или опровергнуть, конечно же) несколько предположений.

Например, одно из основных заблуждений, что система задач обязательно нужна исполнителю, чтобы правильно выбирать себе задачу на день, но это вообще не так. Система задач нужна тому, кто их ставит («начальнику» или «заказчику», кому как удобнее), чтобы не забывать кому когда ты что поручил 🙂

Или ещё мы предположили, что подавляющее большинство менеджмента сейчас происходит в чате, а не в таск-трекерах. Ну, это когда начальник задаёт кучу наводящих вопросов, уточняет что-то там, а потом в конце такой, «ну, сделаешь же»? Не подумайте неправильно, мы не сомневались, что такое существует. У нас были сомнения в повсеместности такого подхода. Сейчас сомнений нет.

Самое забавное, что раньше мы были уверены, что в таск-трекерами совершенно не удобно пользоваться, поэтому ими не пользуются. Общие тормоза, простота интерфейса и всякое такое. А оказывается, таск-трекерами не пользуются (или пользуются из под палки), потому что есть чаты, где сильно удобнее делать всё то, что происходит в таск-трекерах, пусть немного и в хаотичном стиле.

И последнее, чем хочется поделиться, так это разрдажающим сообщением «Ну чё, как дела?» от постановщика задачи в том же чате, в котором задача и ставилась. Похоже, от этого никуда не денешься, это можно только автоматизировать 🙂

#экстрапиар

Продолжаем рубрику #экстракибернетика об интеллекте. И в этот раз цитата про язык. Как всегда, лайк и репост для продолжения.

«Вообразим себе юношу из первобытного племени Ням-Ням. Назовем его для определенности Уу и проследим, как он выполняет функции разведчика.
Уу лежит за толстым старым дубом и неотрывно следит за входом в пещеру на противоположном берегу реки. На восходе солнца сюда подошла группа мужчин из вражеского племени Мань-Мань. Они явно затеяли что-то нехорошее, наверное, оставить в пещере засаду. Они суетятся около пещеры, то входят в нее, то выходят, то исчезают в лесу, то снова возвращаются к пещере. Каждый раз, когда один враг входит в пещеру, Уу загибает один палец, когда один враг выходит из пещеры, он разгибает один палец. Когда враги уйдут, Уу будет знать, оставили ли они засаду и если оставили, то сколько человек. Уу побежит к своему племени и покажет им на пальцах, сколько врагов осталось в пещере.
Почему наш герой имеет возможность, не заходя в пещеру, знать в каждый момент времени, сколько там врагов? Потому что с помощью своих пальцев он построил модель интересующей его части внешнего мира. А интересует его пещера и находящиеся в ней враги. Каждому врагу, находящемуся в пещере, соответствует в его модели загнутый палец. Загнутый палец — это имя врага в пещере, враг в пещере — это значение загнутого пальца. Операции над именами — загибание и разгибание пальцев — соответствуют входу и выходу врагов из пещеры. Это — язык. Его можно назвать языком пальцев, если иметь в виду физический материал, из которого построена модель, или языком чисел, если иметь в виду способ сопоставления имен значениям. И этот язык используется не только, а в нашем примере даже не столько для передачи информации, сколько для построения модели, которая нужна именно как модель — средство предвидеть события, средство узнать косвенно то, что нельзя узнать прямо. Если родное племя Ням-Ням далеко, а Уу не собирается никому сообщать, сколько врагов в пещере, он все равно имеет основания считать врагов, сгибая и разгибая пальцы. Это нужно ему самому для планирования своих действий. Коммуникативное использование языка, т. е. использование его как средства общения между людьми, дополняется некоммуникативным использованием языка в качестве средства построения моделей действительности.
Тут-то, как говорят англичане, лягушка и прыгает в воду. Моделирующая функция языка — тот самый рубикон, из-за которого мы можем говорить о появлении на земле человека. Когда астроном определяет положение планет на небе, затем производит какие-то манипуляции над цифрами и в результате предсказывает, где будут планеты через заданный промежуток времени, он делает в сущности то же самое, что юноша Уу из племени Ням-Ням, когда он загибает и разгибает пальцы, наблюдая за входом в пещеру. Искусство, философия, наука — все это не что иное, как создание языковых моделей действительности.»

​​Противники гибкой методологии и приверженцы подхода «давайте сделаем всё за один раз, но качественно» приводят в пример строительство дома или проектирование автомобиля. Мол, там же смотрите как всё хорошо и делается всё за один раз.

Короче, если этого не видно, не значит что этого нет.

Иногда (а, если честно, почти всегда), очень тяжело остановиться программировать, особенно если очень остановиться надо.

Вот сейчас кипит работа одним прототипом, где, казалось бы, хватило бы связанных между собою статических аштээмелек, чтобы посмотреть на работу прототипа и ещё и другим показать. Но вот оказывается, что одни и те же данные показываются на странице, скажем, юзера и на странице заказа. «Зачем же дублировать? Давайте данные в переменные вынесем». Потом оказывается, что юзеры между собой могут быть связанными и, дабы не усложнять себе и без того копипастсткую жизнь, выносим связи в пишем лёгкий и ненавязчивый map. Потом такой же map появляется в соседних страничках, потом счётчики тоже бы неплохо показать настоящие и приходится писать userts.count. И где-то потом становится очень тяжело остановиться. В какой-то момент приходит светлая идея, что если вот эти вот аккуратно оформленные и структурированные YML-файлы сложить в базу в нужные таблички, то станет чуточку проще. И в итоге я не замечаю как прототип превращается в полноценное приложение.

К рекламе на Фейсбуке зацепил комментарий. Реклама сама об обучении ребёнка программированию и нацелена на американских родителей.

"Unless and until corporations stop sending these jobs overseas, there will be NO opportunities for "coding" in America. I personally know a LOT of people who were replaced by overseas contractors - along with engineers, paralegals, accountants, customer service - just to name a few."

Ну то есть, человек не советует в Америке входить в айти потому, что там уже мы. Как-то не приходилось задумываться, что мы для них проблема.

#dimoneverything

Внезапно оказалось, что четверть всего написанного мною кода пишет нейронный дополнятор.

Ваше следующее задание — оцентровать <div> по вертикали.

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

Так-то придраться к этому факту можно, конечно, уж слишком он субъективен. Но мне подумалось, что главная фишка опытного разработчика в том, что он точно знает как его код будут переписывать потомки и делает так, чтобы после переписывания его кода он стал идеальным. Такая вот мета-разработка выходит.

​​Сегодня опять #экстрастереотипы и в этот раз поговорим о Бритве Оккама.

На всякий случай сформулирую: «Многообразие не следует предполагать без необходимости». Или другими словами это о том, какому из нескольких вариантов объяснения нужно отдать предпочтение — тому, который проще.

Во-первых, попрошу заметить, не Окка́ма, а О́ккама. Но это так, литературная фигня. Ещё вообще не важно, но тоже стоит упомянуть, что сам Уильям Оккама ни о какой бритве знать не знал, это просто его именем назвали принцип сильно позже.

Во-вторых, это не никакой не закон, а всего-лишь презумпция. Это значит, что основывать свой выбор только этим принципом никак нельзя. Бритва может помочь сэкономить время, выбрав какую гипотезу следует проверить раньше других. Не надо вот этих «давайте в базе две таблички, а не три сделаем, потому что Бритва Оккама», да? Может две, а может три, тут надо проверять. И да, логичней сначала проверить две.

Во-третьих и самых главных, нельзя сравнивать два абстрактрых объяснения между собой этим принципом. К двум утверждениям «давайте данные Монго будем складывать» и «давайте лучше в Постгрес и рядом Редис ещё развернём» Бритва применима? Подсказывает ли Оккама нам, что лучше начать с Монго, вместо Постгреса с Редисом, потому что там два, а тут один? Нет! Из двух утверждений «А вместе с Б» и «только В» вообще нельзя делать никаких выводов, потому как совершенно нельзя определить что из этого проще. Вполне может оказаться, что А+Б выйдет сильно проще, чем В. А может и не выйдет, Оккама тут бессилен вам помочь, давайте уж как-нибудь сами.

А вот то, о чём Бритва Оккама действительно говорит, что если что-то можно объяснить с помощью утверждений А и Б или только с помощью А, то стоит отдать предпочтение только А. Из двух утверждений «давайте обойдёмся только постгресом» или «давайте рядом с постгресом ещё и редис лупанём», лучше сначала потратить силы и попробовать обойтись только постгресом, а потом пробовать что-то рядом запускать.

Самое интересное занятие при разработке — придумывать полезные функции.

«Эти все паттерны-шматерны, софт-скиллы и знания третьего ангулара это, конечно, хорошо, но самый важный инструмент, который есть у разработчика — это возможность принимать решения. И брать за них ответственность, само собой»

У бота, через которого отправляются посты в «Экстраполяцию» всё меньше и меньше конкурентных преимуществ. Раньше были каменты в фрейме, сейчас они нативные. Раньше хотелось отложенных записей, телеграм это умеет сам. Теперь вот лайки завезли.

Если честно, отношение двоякое. Сначала была твёрдая уверенность, что телеграмм — это такая себе платформа, где каждый может себе слепить то, чего хочется, с кнопками, реакциями и вообще всем, чем хочешь. А сейчас всё больше ощущения очередной реинкарнации ЖЖ.

Не то, чтобы это было плохо. Уверен, создатели телеграм тоже задумывали его, как платформу, а потом пришли настоящие пользователи и захотели вот это вот всё.

Волею случая ко мне в руки попал проект, который писала одна аусорсинговая фирма, название которой я, конечно же называть не буду. И в процессе детального его изучения, обнаружился тест вот такого вот содержания:


expect(client.phone).to eq(client.phone)


Увидев такое, я, сам того не замечая, прошёл все стадии знакомства с легаси: гнев, отрицание, желание переписать и попытки пофиксить. В итоге, обретя катарсис, я занялся тем, чем следовало бы заняться с самого начала — поиском причин появления вот такого вот странного теста. Сперва были отметены какие-либо разумные причины, вроде каких-то побочных эффектов вызова геттера — всё было так, как выглядело, обычный геттер, который так же обычно читается. Потом в ход пошла история изменений файла и сопуствующие изменения в коммите. Ну и, конечно же, коммит-каменты.

Во-первых, хочу напомнить, что именно для вот таких вот случаев и нужно группировать изменения атомарно и давать внятные пояснения не того, что происходит в коммите, а того, зачем это происходит.

Во-вторых очередной раз убедился, что скваш (squash) коммитов — это неудобно.

В-третьих добавлю, что комментарии в гит-коммите должны быть самодостаточны. Комментарии, вроде Fixed issue CN-ERT-5553, наверное, помогают быстрее писать комментарии и быстрее принимать пулл реквесты, но совершенно теряют историческую ценность. Как вы понимаете, своим внутренним баг-трекером писатели кода делиться не собирались.

В итоге дедуктивного расследования выяснилось, что в какой-то момент деньги стали заканчиваться быстрее, чем набор несделанных фич и приходилось на чём-то экономить. И экономить начали на времени разработки. Сначала тест появился, как следует, с внятной плоской проверкой, вроде eq('+380999999999’). Потом попросили писать номер в определённом формате. Добавив валидацию, оказалось, что создание объекта для теста выходит чуточку сложнее. В итоге сначала убрали все вольные создания объектов и заменили на системный фабричный подход и тут (внимание) упало несколько тестов, которые говорят, мол, у вас там какой-то непонятный международный формат, а у нас тут надо просто кучу девяток. И программист в спешке решал чему же должен быть равен сгенерированный случайный номер телефона по определённому формату. Оказалось, что номер телефона строго равен номеру телефона и больше ничему другому не равен. Просто удалить тест он, конечно же, не мог, потому что падающие метрики никому не нужны.

Виноват ли этот программист? Определённо нет, по истории коммитов видно под каким давлением со стороны заказчиков и руководства приходилось исправлять неисправленное. Может быть, руководство аусорса как-то лучше могло себя показать? Вряд ли, счета по проекту внезапно грозили быть неоплаченными и нужно было срочно доделывать обещанное. Может быть, заказчику нужно быть дальновиднее? Тоже нет, ему просто выставляют счета и обещают фичи.

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

Я тут внезапно осознал, что программирование — это магия. Та самая магия, из книжек, когда можно сделать что-то такое, что выглядит в разы проще и эффективнее прямого влобного способа. Ну ладно, почти такая же магия, только не нарушающая закон сохранения энергии.

И самое интересное, что это работает на всех уровнях абстракции. Ну, вот пишу я в специальном файлике resources :projects, а оно мне подготавливает целый набор урлов с правильными гетами, постами и патчами, которые указывают на специальные классы и методы в этих классах. Причем, если написать resource :project будет почти такое же самое, но, как говорит Василий Иваныч, есть один нюанс.

И, конечно же, высшие маги знают что и как там происходит под капотом и умеют применить это заклинание куда более эффективно, дописав какой-то неочевидный параметр или используя метапрограммирование, но магия не перестаёт быть магией — одно простое заклинание делает то, что вручную делать сильно сложнее.