2631
Канал об IT в целом и о программировании в частности. На канале объявлено военное положение и поэтому по вопросам рекламы пишите: @aratak, а деньги отправляйте сюда: https://send.monobank.ua/jar/97f7LwGQJF
Сейчас стало крайне модным отвязывать себя от какой-то конкретной технологии и считаться неким «специалистом, который все может и не надо ему указывать какие инструменты ему использовать». Безусловно, крайне похвально с точки зрения технической подкованности самого специалиста. Но это же крайне опасно с точки зрения проекта и остальных его участников. Подумайте сами, если только что нанятый специалист в команду считает, что вон тот кусочек приложения было бы крайне эффективно переписать на языке-который-никто-кроме-него-не-знает, то последнее, что нужно делать — это переписывать это на том самом языке.
Умение работать в коллективе — одна из важнейших характеристик разработчика и не редко именно с этого нужно начинать собеседование. Понимание способностей и предпочтений всех своих коллег — главная характеристика умения работать в коллективе.
В Нидерландах, в семнадцатом веке, покупкой и продажей тюльпановых семян занимались цветоводы и ценители, что не удивительно. Но в какой-то момент в процесс покупки-продажи тюльпановых семян включились непрофессиональные спекулянты, сделали из этого фьючерсы и цены на луковицы некоторых сортов тюльпанов многократно выросли. Через некоторое время, из-за огромного ажиотажа, цены на обычные тюльпанные луковицы тоже пошли вверх и тоже стали объектом фьючерных торгов спекулянтов. Потом к этому процессу подключились и те, кто не был ни цветоводом, ни спекулянтом, а просто хотел заработать на хайпе. Говорят, это был первый в истории биржевой пузырь, потому как через полтора года цены рухнули и начались многолетние тяжбы между продавцами и покупателями ничем не обеспеченных тюльпановых контрактов. К слову, на пике своей популярности луковица редкого сорта тюльпанов стоила, как три годовых дохода ремесленника средней руки.
«Не смехотворно ли платить золотом за бесполезные корневища?», спрашивал какой-то там историк спустя полтора века. Да, уж. Через полтора века наверняка уже смехотворно.
Понятие «покрытие тестами» нужно только разработчику. Этот критерий говорит тебе какое место приложения ни разу не запускалось (помним о вышеупомянутых правилах и о том, что консоль запускать вообще не надо). В итоге получится, что непокрытый тестами код ни разу не запускался вообще при разработке и, возможно, попадет на рабочий сервер так ни разу и не проверенным. Поэтому вопрос написания тестов должен звучать так: смогу ли я написать программу ни разу не запустив интерактивную консоль и сервер при разработке или не смогу? Кроме того, при такой стратегии разработки понятие полезного и бесполезного теста просто лишено смысла. Если разработчик захотел что-то проверить, он обязательно напишет тест. Если ему не захотелось проверить код по какому-то условию, то теста на это не появится в принципе. Последним по списку, но никак не по важности является тот факт, что длинные методы в стиле спагетти, которые делают несколько вещей сразу, просто неудобно писать. Это же еще проверять тестами нужно!
Читать полностью…
Тесты в первую очередь — механизм проверки того, что-то, что написано — работает. Вопрос не в том, необходимо покрывать тестами или нет, а вопрос в том, как убедится, что только что написанный код работает. Существует несколько неправильных способов писать рабочий код. Можно открывать интерактивную консоль, выполнять код там и копировать его внутрь методов, можно использовать дебаггер для перехвата управления приложением и опять же, в интерактивной консоли пробовать угадать рабочий код. Можно после каждого изменения в любом месте перезапускать сервер (возможно, в вашем фреймворке есть способ делать это автоматически) и вручную проверять поведение приложения в целом. А можно попытаться автоматизировать этот процесс и проверять код сразу в тестах. В итоге появились три запрещающих правила:
1. Табу на использование интерактивной консоли в процессе написания кода.
2. Запрет на дебаггер при разработке.
3. Нельзя держать запущенным приложение локально, чтобы иметь возможность кликать, и проверять результат.
Соблюдая эти три нехитрых правила не писать тесты просто не получается.
В современном мире айти-разработки, при преобладании удаленной работы и сотрудничестве с фрилансерами появился занятный феномен перекладывания ответственности за простой в работе. В офисном мире, если у программиста нет задач, он может делать что угодно и ему за это все-равно заплатят, он же в офисе! У фрилансеров же обратная ситуация. Почему-то принято считать, что отсутствие задач у фрилансера (или удаленного сотрудника) – это проблема самого фрилансера. Решение выбирают фрилансеры вполне логичное и очевидное — берут себе несколько проектов и постоянно переключаются между ними. Из-за этого, собственно, и пошла легенда, что фрилансером быть тяжелее, чем офисным сотрудником.
А быть должно все наоборот. Только никому не говорите, что это я вам рассказал. Ставьте сами себе задачи с формулировкой «Мне же все-равно нечего делать, поэтому буду делать вот эту полезную задачу. Остановить меня можно только другой задачей». Профессиональным будет считаться не только качественное выполнение таких задач, тщательное описание до и отчет после, но и адекватность поставленных задач. Очевидно, что задач вида «перепишу-ка я вот этот модуль, потому что там код – говно» быть не должно в принципе, а вот формулировка «помнится, заказчик давно хотел вот эту фичу, а сейчас как раз подходящий момент, чтобы ее сделать» крайне удачная. Дополнительной выгодой от такой стратегии поведения будет демонстрация руководству проекта (менеджеру, если хотите) того, как по-вашему должны выглядеть поставленные вам задачи.
Эффекта от такого поведения может быть два. Или менеджер поймет, что если у вас нет задач, то вы начнете делать что-то не то и начнет суетиться. Или менеджер поймет, что и без дополнительного контроля вы делаете все правильно.
Можно провести аллегорию с производством цемента. Если доменную печь, где происходит обжиг мергеля, остановить, то печь начнет остывать, если она остынет, то кирпичи немного уменьшатся от остывания и начнут сыпаться. Остановка доменной печи — гораздо более дорогая операция, чем поддержание температуры в доменной печи даже без сырья и производства, чтобы температура была достаточно высокой. Поэтому обжигать нужно постоянно и отсутствие сырья уж никак не проблема печи.
Мы живем в век технологий, когда любая амбициозная идея, которая хоть сколько-нибудь гипотетически возможна, априори считается реализуемой технически. У большинства даже не возникает сомнений в эмуляции этих самых магических способностей. Вера в компьютерных духов непоколебима.
Три-дэ колонки с автоопределением помещения, искусственный интеллект в телефоне который понимает естесственную речь, личные картины Ван Гога в инстаграме с помощью фотокамеры, читалка в телефоне, следящая за глазами пользователя. Список эмуляций магии можно перечислять бесконечно. Чудес не бывает, мы все еще заперты в тьюринг-полноте и выбраться пока возможности не видно. Это мы, люди, подстраиваем себя и свои нейронные сети под программы, а не программы подстраиваются под нас, ведь это значительно проще и нам и программам.
Порой даже человеческому оппоненту не выходит донести какую-то конкретную мысль, а уж требовать от компьютерной программы абсолютного понимания — слегка перебор. Это я о возможном искусственном интеллекте говорю. И давайте сразу пример.
Просите вы своего соседа буквально «подай мне вот ту хрень» и показываете пальцем на стол, где лежит несколько разных «хреней», но сосед безошибочно определяет какую именно, руководствуясь тем, что настольную лампу, пачку скрепок и подставку под чашку просить вы вряд ли будете, а бумагу, ручку и линейку «хренью», как правило, не называют, потому как названия распространенные и часто употребимые. Опять же, контекст того, чем вы конкретно занимаетесь, поможет соседу понять, что вам прям сейчас нужен степлер (или, скажем, дырокол). Назвать такое вот поведение соседа уж слишком интеллектуальным, наверное, нельзя. Да, оно контекстно-зависимое и довольно сложное, относительно текущих мощностей вычислительных систем и текущего уровня развития тьюринг-полных алгоритмов, но назвать эту умозаключительную цепочку чем-то сверхъестественным для современных программ нельзя.
Или с другой стороны, когда пишется программа на каком-либо языке, компьютер требует однозначности понимания написанного без каких-либо поблажек. Контекст, отношения, зависимости, нотацию, семантику, логику и все прочее выстраивать нужно программистам. И только лишь от них зависит насколько вольная форма будет во взаимодействии с этой программой.
В итоге понятно, что тьюринг-полный искин из прошлого поста — это всего лишь качественно проработанная программа, хоть и гипотетическая. И написана она программистами или же другими, более слабыми искинами. И в программе этой уже просто так не разобраться. Такие вот программы, которые очень тяжело описать алгоритмически вне зависимости от того, доступен ли ее исходный код или нет называют «магией». Перефразируя третий закон Артура Кларка: «любая достаточно сложная программа неотличима от интеллекта». В итоге любую программу можно назвать «искусственным интеллектом» если логика работы программы достаточно сложная, и в ней не разобраться за вменяемое количество времени.
Этот доклад с какого-то митапа (а судя по залу, людей там не слишком много) я пересматриваю где-то раз в пару месяцев и каждый раз смеюсь до слез. Сойдет за субботнюю развлекательную программу?
Читать полностью…
Ребята, три темы на выбор и я прям не знаю с чего начать. Как думаете, о чем написать? Вам слово.
🎓 Где находится в программировании филология.
💩 Как админам правильно смотреть на код разработчиков.
🛣 Почему мэр виноват во всех ямах на всех дорогах города.
Так, неделю назад мы выяснили, что нас тут подавляющее большинство айтишников в целом и разработчиков в частности. Конечно, это было более-менее очевидно, но, как говорил мой школьный учитель по физике, у очевидной вещи зачастую более сложные доказательства, чем у неочевидных на первый взгляд.
Сегодня мы выясним откуда же мы. Итак:
Сегодня опять субботний анекдот с альтернативным юмором. Вспоминаем булеву алгебру и смеёмся :-)
Заходят три логика в бар. Бармен спрашивает:
— Кто-нибудь будет что-нибудь пить?
Первый:
— Не знаю
Второй:
— Не знаю
Третий:
— Нет.
Чтобы доказать свою правоту в спорах, последнее что нужно делать, это приводить аналогии. Ведь сразу же после приведенной аналогии собеседник начинает спорить с приведенной аналогией, а не с изначально высказанной мыслью. И спор после этого уходит в неправильное русло. Кроме того, аналогии приводятся от бессилия найти нормальную аргументацию. Не используйте аналогии в спорах.
Читать полностью…
Во многих языках есть штука, которую называют «тернарным оператором». Как правило, эта штука записывается, как 'c ? t : f'. Штука замечательная, без споров, но вот её название звучит как-то коряво.
Даже если вы не знаете латинского, то совершенно очевидно, что смысл слова «тернарный» означает «тройной», что по сути сводит смысл оператора к тому, что у этого оператора три, вместо двух аргументов. Ну, вот оператор сложения (a+b) — с двумя аргументами, но мы не называем его «бинарным оператором», так как таких операторов у нас много и совершенно непонятно о каком конкретно операторе речь. А вот тернарник у нас один, и все как-то привыкли, что «тернарный оператор» — это на самом деле «условный оператор в тернарной форме».
Это если бы в маленьком городке жил один негр по имени Степан Илларионович, а всё село его бы вместо этого называло «Негр». Потому что он у них такой один. Вот такое себе легкое проявление расизма в программировании, ребята.
Некоторое время назад был опрос о том, насколько много среди нас не айтишников. Совершенно не представляю что тут делают 10% неайтишников, но мне невероятно приятно, что в читателях канала есть еще и такие :-) Спасибо.
А давайте теперь посчитаемся с точки зрения профессии в айти. Итак:
🌚 - бэкэндер
🌝 - фронтендер
🌷 - дизайнер
🐼 - менеджер
🎱 - другой айтишник
🗿 - вообще не айтишник
Голосуем!
Завтра утром напишу о собачьем пин-коде. Судя по прошлонедельному опросу, название достаточно интригующее. Как вы думаете, о собаках это или о банковской системе пост будет?
Читать полностью…
Давайте на секундочку представим, что у нас нет никаких СУБД и данные есть в оперативной памяти в виде обычных структур данных. Идеальное решение по скорости доступа, идеальная интеграция с бизнес-логикой.
И тут же появляется первая проблема рестарта приложения, ведь хочется не терять данные. И тут эволюция компьютеров не придумало пока ничего другого, кроме как сохранить эти данные на жесткий диск. И только вопрос в том, как это сделать. Транзакционность, распределенность, конкурентность, производительность. Это все, конечно же интересно, но сейчас мы говорим о том, что же все-таки сохранять в файлике, а что нужно считать в реальном времени в бизнес-логике.
Если мы наши данные будем как-то стандартизировать и просто записывать в файл, то рано или поздно (но скорее рано) захочется рядом с данными держать еще и вычисляемые данные, вроде count, max, order_by и ортогональные срезы данных, вроде where, where-join и union. Так или иначе это делать нужно и вопрос только в том, где это делать и в каком формате.
И тут с легкостью обнаруживается, что это стандартная проблема абстрагирования и инкапсуляции логики. Можно четко сформулировать проблему, где будет вполне ясно сказано где у нас просто данные, а где вычислимые данные и валидации этих данных. И вдруг окажется, что бизнес-логика, со всеми манипуляциями инвойсами, юзерами и чем-там-у-вас-еще должна быть железобетонно отделена от слоя, где эти данные денормализуются, валидируются, транзакционируются и все прочее.
Окажется, что ту часть любого приложения о которой мы с вами сейчас говорим, можно абстрагировать до следующей цепочки:
(`Б` - бизнеслогика) -> (`Д` - денормализация) -> (`П` - персистентность)
Тогда вопрос и все мнения можно свести лишь к приоритету операций. К тому, что у вас конкретно инкапсулировано: Д+П или просто П. Соответственно, если Б недостаточно отделено от Д, то может сложиться впечатление, что Д — это часть Б, но это очевидно, что не так.
А если приложение написано нормально, и Д достаточно отделено от П, то совершенно не важно где конкретно вы занимаетесь Д.
(Б + Д) + П — плохо
Б + (Д + П) — немножко лучше
(Б) + (Д) + (П) — хорошо
Внимательно сравнив эти три варианта, становится понятно, что до тех пор, пока бизнес-логика ничего не знает о денормализации, и абстракция денормализации не протекает, то совершенно не важно где конкретно денормализуются данные.
Беда только в том, что в попытке достичь варианта (Б) + (Д) + (П), неизбежно получается вариант (Б + Д) + П.
Очевидно, что арбалет, как устройство появилось значительно позже лука. Проблема, которую решал создатель арбалета достаточно проста и очевидна — хотелось сохранить кинетическую энергию натянутой тетивы без участия мускулатуры стрелка. В итоге арбалет получился более громоздким, менее дальнобойным, более дорогим в изготовлении, менее скорострельным, менее убойным на средних дистанциях. Лук (особенно длинный лук) уделывал арбалет по всем показателям, тем не менее, после популяризации арбалета практически все армии так или иначе использовали в первую очередь именно арбалет, а не лук. И причина этому очень простая.
Чтобы вырасти и Робином Гудом и сделать так, чтобы стрела хотя бы летела в нужном направлении, не говоря уже о хоть какой-нибудь точности, нужно потратить не один месяц, а может быть даже и не один год. А получить целый отряд справных лучников, работающих в команде, еще менее вероятно и более тяжело. А вот с арбалетами и арбалетчиками все намного проще, ведь пары часов инструктажа вполне достаточно, чтобы организовать заградительную стену стрел в ближайшей стычке с врагом. Экономически и стратегически легче найти и нанять десять арбалетчиков и вручить им десять арбалетов, чем воспитать одного лучника.
Само собой, сеньор-лучник будет в пять раз лучше любого джуниора-арбалетчика и бюрократии для одного лучника не требуется вовсе. И организовывать командную работу одному лучнику не нужно. На десять арбалетчиков нужно еще одного тим-лида, пару офис-менеджеров и одного кадрового агента, чтобы заменять убитых и уволенных арбалетчиков и придворного организатора праздников, чтобы развлекал толпу арбалетчиков, пока те не стреляют. В итоге владение луком стало приятным бонусом при найме арбалетчиков, а потом лук и вовсе перерастёт скорее в хобби, чем в основную профессию. Хотя, безусловно, на конференциях арбалетчиков говорят все исключительно о том, как правильно владеть луком и как сильно техника владения луком помогает стрелять из арбалета. И что на десять арбалетчиков в команде нужно иметь пару лучников. И что если бы все десять тысяч арбалетчиков в регулярной армии владели бы луком, то можно было бы и Византию захватить.
Но все мы знаем, что в результате побеждает стандартизация, а не профессионализм.
Не все согласны с мнением относительно табу на использование интерактивной консоли. Иногда консоль может быть крайне полезной и удобной. Она же может позволить избавиться от ненужных тестов, проверить быструю гипотезу и много еще чего такого. После вчерашнего поста мне прислали ссылку на статью, где автор как раз рассказывает что по его мнению должна делать хорошая интерактивная консоль. Очень хорошая и полезная статья, рекомендую к ознакомлению.
Она напоминает о таком режиме программирования, которую многие называют «спайк». В этом режиме разработчик понятия не имеет как будет выглядеть будущая программа, какой у нее будет интерфейс и какая архитектура. Он просто творит. Это очень полезный вид разработки, который должен сформировать полную и целостную картину того, как должна выглядеть будущая программа, но не более. Но писать настоящий код в таком режиме нельзя. После сформировавшегося мнения о будущей программе весь спайканый код нужно удалить и начать писать нормальный код с тестами и проверками.
Прочитал я тут статью и придумал профессию недалекого будущего в нашей отрасли. «Чтец новостей и отвечатор на вопросы» а-ля «Делфийский оракул». Чтобы с утра и до вечера читал и следил за всеми новостями и бложиками. Программировать времени у него точно не останется.
sergiodxa/how-to-keep-updated-with-the-javascript-ecosystem-97c8e36c2c3f" rel="nofollow">https://medium.com/@sergiodxa/how-to-keep-updated-with-the-javascript-ecosystem-97c8e36c2c3f
Ребята, я вернулся! Давайте назовем этот перерыв творческим отпуском, процессом переосмысления и познания себя или как-нибудь так. И я очень рад, что вы все еще со мной!
За последние два месяца тишины на этом канале произошло много чего интересного и хочется обсудить с вами все и сразу. Во-первых телеграм стал переполнен разнообразными каналами на любой вкус и цвет, обо все на свете и в каком угодно виде. Безусловно, это кажется хорошим знаком, но меня вот расстраивает упавшее качество содержимого этих каналов и засилье рекламы и «взаимного пиара» между каналами. Хочу очередной раз заметить, что платной рекламы в канале «Экстраполяция IT» нет и не будет. Еще напоминаю, что на этом канале нет еще и новостей. Что там ест на завтрак Илон Маск, как сильно подорожал биткоин и сколько лет очередной бабушке, создавшей мобильное приложение вы с легкостью узнаете на других каналах. А я слишком вас всех люблю, чтобы попусту тратить ваше время.
Кроме того, раньше в канале выходило по пять-семь выпусков в неделю и придерживаться такого темпа, при этом не теряя в качестве содержимого увы, не выйдет. Хотя я уверен, что два-три выпуска в неделю можно смело вам обещать. Качество значительно важнее количества, ведь так же?
С уважением, «Экстраполяция IT».
Вспомните только когда перестает быть интересным играть в компьютерные игры в режиме «против компьютера». Когда с завидной точностью можно предсказать поведение ботов в игре. Вначале, как только знакомишься с хорошей игрой, поведение «автоматонов» выглядит непредсказуемым и интеллектуальным. Поиграв немного, человек обучается и запоминает предыдущий опыт. А боты в играх — нет. И «хорошим ИИ» считают тот, который предсказать можно реже остальных. «Идеальным ИИ» назовут такого игрового бота, которого нельзя будет предсказать, потому как его поведение будет постоянно совершенствоваться и изменяться. Знаете ли вы игры, в которых ИИ обучается на поведении игрока (или всех игроков в мире)? Напишите мне личным сообщением, я вот таких игр не знаю.
Читать полностью…
Язык программирования в первую очередь — язык. И относиться к нему нужно исключительно как к языку, как относятся к нему лингвисты и филологи. И не путайте, пожалуйста, алгоритмизацию с программированием. Та логическая цепочка действий, которая приводит к желаемому результату совершенно отвязана от технологии и языка программирования. Алгоритмизация существует вовне и скорее похожа на мысль, чем на формулировку этой мысли в виде фразы на конкретном языке.
Представьте себе, что человечество все-таки разработало искусственный интеллект, основываясь на тьюринг-машине. Конечно же, понадобилось тонны кода и огромные производительности, но в результате мы получили такую себе «думающую машину» (или даже лучше сказать «псевдо-думающую машину»). Ну, то есть технически, конечно, это будет обычная программа, которая ничем принципиально не отличается от нейрогенератора кошечек, эмулятора Ван Гога или системы, распознающей в каракулях пользователя картинки, но эта наша гипотетическая псевдо-мыслящая программа уже настолько сложна, что по всем канонам научной фантастики уже ничем не отличима от интеллекта. И общаться с такой системой мы будем, посредством какого-то формального языка, который понимает эта система. Скажем, «Сири» или «Окейгугл» понимает русский язык, а вот «Алекса» — нет. Сири хорошо может ответить на вопрос о том, нужно ли брать зонт на улицу или нет, ведь программисты позаботились о том, что вопрос о зонте качественно ассоциируется с погодой и конкретно наличием дождя.
А вот язык программирования же (который по своей сути является такой же программой, как Сири, просто более низкоуровневой) требует некоторых формальностей в общении и как правило обязует быть однозначным и оставаться в пределах своей семантики. И общение с компьютером посредством языка программирования технически не отличается с общением с аборигенами из предыдущего поста — нужно принять законы построения мысли и оперировать лишь тем, что доступно в пределах этой семантики.
Да, вы все правильно поняли, в одном из смайликов страшный спойлер.
Читать полностью…
У каких-нибудь коренных племен каких-нибудь островов какой-нибудь Новой Зеландии может быть свой язык, терминология которого в корне не совпадает с другими языками. Сам принцип построения предложений и формулировка мысли может в корне несоответствовать тому, к чему мы привыкли. Скажем, у такого племени нет понятия «лево» и «право», а ориентируются в пространстве аборигены исключительно по сторонам света. У них есть понятие «южнее» или «восточнее», а приложение-навигатор будет объяснять не относительное положение поворота, а абсолютное. «Через сто метров держитесь южнее» или как-то так. Давайте для сгущения красок этой аллегории предположим, что у этого же племени не существует вопросительных предложений, а только лишь утвердительные. И вместо вопроса, допустим, «Как пройти в библиотеку?» на этом языке канонично говорить «Ты мне должен показать дорогу в библиотеку». И, чтобы еще сильнее вас запутать, давайте скажем, что этот язык напрочь лишен местоимений и числительных. Пример с библиотекой с этим новым правилом будет звучать, как «Чака должен показать Фасимбе дорогу в библиотеку». А Чака такой в ответ «Обезьяноподобным шагом на юго-восток и потом медвежий шаг на юг».
А теперь давайте подумаем, удобный ли этот язык для повседневного общения? Для аборигенов — безусловно. Они не знают как начать думать так, чтобы вообще захотелось сказать междометие «я», относительное направление или хоть какое-нибудь числительное. Для них тот мир вполне естественен и удобен, а наш с вами привычный мир для них по-уродски неприветлив. Верно же? Кстати, особым спросом пользуются полиглоты, в совершенстве владеющими семантикой и аксиоматикой нескольких языков.
Сейчас очень модно рассуждать на тему того, что настоящий программист не должен привязывать себя к какому-либо языку и должен мыслить категориями, выходящими за рамки конкретного языка или парадигмы. Мол, формулировка собственной профессии или должности, вроде «PHP-разработчик» или «HTML-верстальщик» обречена на провал и с такими людьми лучше не стоит иметь дело. А дело как раз и состоит в том, что язык программирования в первую очередь — это язык, а во вторую — программирования. И важно знать на каком языке думает программист, чтобы понимать его основу мышления и точку опоры в дальнейших дискуссиях. Не спрашивайте на каком языке программирования умеет программировать собеседник. Спрашивайте на каком языке он думает.
Добрый вечер, ребята!
Сегодня хотелось бы вернуться к теме мгновенного обмена сообщениями в нашей профессиональной деятельности. Когда-то чатов в профессиональной деятельности, как таковых, не было вообще — вполне хватало почты и личной беседы, удаленной работы не существовало, а удаленно общаться нужно было с клиентами-заказчиками. В те далекие времена об удаленной работе вообще никто не думал по многим причинам и чаты воспринимались, как развлечение и средство таких себе удобных и дешевых СМС с компьютера на компьютер. Мы же все еще помним что такое СМС? Были чаты вообще, но их никто не ассоциировал с разработкой и работой вообще. Скайп был нужен только, чтобы поговорить голосом в назначенное время, а в аськи и джабберы воспринимались, как нечто вообще не связанное с работой. Сейчас же, в эпоху тотальной удаленной работы, чаты выполняют ту самую роль рядом стоящих, попивающих кофе коллег, которые по счастливой случайности находятся недалеко от твоего рабочего места и болтают о какой-то невообразимой фигне, пусть даже и связанной с текущим проектом. И ваш личный выбор слушать их одним ухом, а вторым программировать или одеть наушники с белым шумом и наконец-то начать работать двумя ушами сразу.
Конечно же, основной аргумент в пользу необходимости подслушивать такие разговоры слишком шаток и неубедителен. Звучит он где-то как «а вдруг я пропущу что-то важное!». С другой стороны этих морально-этических баррикад расположились любители белого шума в наушниках. Те, кто любит работать в сферическом вакууме. Они вообще не читают публичный чат до тех пор, пока их отдельно об этом не попросить в личном сообщении или телефонным звонком. И сильно раздражаются, если их туда вызывают на какую-то дискуссию.
В итоге имеем два лагеря пользователей групповых чатов: первая очень сильно отвлекается на них, вторая ими не пользуется, как чатами. И полезность чатов для этих двух групп сведена к минимуму.
И, конечно же, как и во всех правилах, и в этом есть исключение. Существует небольшое количество случаев, когда чатовый способ общения внутри команды более оправдан любого другого способа коммуникации. Это когда вас всего двое. Или трое. Ну, максимум четверо. В остальных случаях к чату нужно относиться, как к трёпу в курилке или на кухне и ни в коем случае не держать там важной информации и уж тем более заниматься в них управлением проекта. И абсолютно не важно сколько ботов и автоматонов вы добавите в ваш слэк — он все еще будет курилкой вашего виртуально-удаленного офиса, просто курить там будут еще и роботы.
«Любой опытный программист пишет бабайко-устройчивый код, под бабайкой каждый понимает свой собирательный образ грабли, ударившей его по носу огромное число раз. У очень большого числа программистов это реюзабельность, у других, например, отказо-устойчивость, у третьих, "сложность" . Человек решил побороться со своей бабайкой, что вызывает уважение, но делает это достатачно топорно и не понимая, что это не объективная проблема, а его бабайка, что прискорбно.»
Читать полностью…
Сегодня вспомнили о замечательном тексте с названием "Число Грэма на пальцах". Текст большой, но настолько прекрасен, что стоит потраченных на него 20 минут. Цитата из статьи для затравочки:
«Рассчитывать его бесполезно, да и не получится. Количество степеней здесь не поддается осмысленному учету. Это число невозможно представить, его невозможно описать. Никакие аналогии на пальцах™ неприменимы, число просто не с чем сравнивать. Можно говорить, что оно огромно, что грандиозно, что монументально и заглядывает за горизонт событий. То есть придать ему какие–то словесные эпитеты. Но визуализация, даже вольная и образная — невозможна. Если с тремя стрелочками еще хоть что–то удавалось сказать, нарисовать безбашню от Земли до Марса, как–то с чем–то сопоставить, то тут аналогий быть просто не может. Попробуйте вообразить себе тонкую башню из троек от Земли до Марса, рядом еще одну почти такую же и еще одну, и еще... Бескрайнее поле башень уходит вдаль, в бесконечность, башни повсюду, башни везде. И, что самое обидное, эти башни даже отношения к числу не имеют, они лишь определяют высоту других башен, которые нужно построить, чтобы получить высоту башень, чтобы получить высоту башень... чтобы через невообразимое количество времени и итераций получить само число.»
Приятного чтения!
http://sly2m.livejournal.com/620353.html
Сегодня опять анекдот, связанный с программированием. Этот — мой любимый. И анекдот этот до того странный что с него вряд ли получится посмеяться. Хотя как посмотреть, я вот ржал, как первый раз услышал его.
Первый контакт человечества и инопланетной расы. Инопланетянин и человек долго смотрели друг на друга, и вдруг инопланетянин говорит:
— Вокруг нас десять кратеров.
— О, я понял! — восклицает человек, — я вижу четыре кратера, значит вы используете систему исчисления с основанием четыре.
— Нет, — отвечает инопланетянин, — мы используем систему исчисления с основанием десять. А что такое «четыре»?
Попробуйте на слух отличить фразу «идет снег» от «инопланетные существа высадились на соседнем поле» на каком-нибудь суахили. Разница в паре звуков возможно может быть существенна, а может быть всего лишь случайным дефектом речи у конкретного произносящего. А собаки на слух вряд ли смогут отличить между собой слова «интерференция» и «интерпретация», потому как их слух и мозг не рассчитаны на тонкости понимания человеческой речи и конкретно русского языка. Вот даже если у вас никогда не было собаки, то вы наверняка знаете, что есть две основные команды, которым собак учат первыми: «нельзя» и «взять». Также есть вариации этих же самых команд в виде нелепых слов «фу» и «фас». Учить собаку, само собой разумеется, нужно диагональным командам — либо «фу» вместе с командой «взять» либо «нельзя» вместе с «фас». И фишка состоит в том, что случайно взятый человек не знает на какие команды натренирована собака, а ошибка в произнесении неверной команды может быть катастрофической. И естественно, лучше не давать никаких подобных команд чужой собаке, а то укусит поди, и еще и будет права. Пин-код на банковских картах или код блокировки на телефонах выполняют приблизительно ту же функцию, что и вариация собачьих команд — они призваны защитить от случайного постороннего вмешательства. Конечно же, целенаправленное зловредительство никак нельзя защитить никакими в мире паролями на телефонах, собаках или картах. Для этого существуют другие методы.
К чему это я. Зайдите на свои сервера и поменяйте порт ssh-доступа со стандартного двадцать второго на какой-нибудь другой. На двадцать третий или двести двадцать четвертый. На серьезные целенаправленные взломы это никак не повлияет, но вот от случайного бота, бродящего по сети и выискивающего свежие дыры в безопасности, это может спасти. Пройдет мимо, не обнаружив открытый двадцать второй порт.
Скажите мне, друзья, публиковать ли подобные ссылки на интересные статьи из интернета в будущем? Если публиковать, то это будет достаточно редко и только на те статьи, которые удовлетворяют двум условиям: интересны вне зависимости от времени прочтения (не новости) и достойны нашего внимания.
Читать полностью…