2631
Канал об IT в целом и о программировании в частности. На канале объявлено военное положение и поэтому по вопросам рекламы пишите: @aratak, а деньги отправляйте сюда: https://send.monobank.ua/jar/97f7LwGQJF
Один из самых серьёзных аргументов против использования гибких методологий основан на примере строительства дома. Говорят, мол, «как вы, Адепты Великого Оджайла построите дом без чертежей, плана и на ходу переделывая архитектуру?». Еще в подкрепление своих слов приводят в пример картинку с домом, основанном на подпорках, разных способах постройки, который вот-вот развалится.
Так вот, полуразваленный недостроенный дом без документации — это не гибкая методология, а это отсутствие какой либо методологии. Такую методологию я называю «бегущий лось во время лесного пожара». Не стоит путать, друзья.
Гибкая методология разработки в первую очередь включает в себя выпуск некой версии продукта, которой уже можно пользоваться, но она все еще сырая и нуждается в доработке. А уж потом разработка новой функциональности в зависимости от желания пользователей. И в этой вот аналогии со строительством дома наша гибкая методология — это полностью построенная, готовая к эксплуатации новостройка. Дальше разработка жилья происходит прям в процессе эксплуатации. Вы же каждое утро слышите этих Адептов Аджайла с перфоратором в руках, да?
Искусственную эволюцию (эволюцию мысли) наблюдать значительно проще, чем естесственную эволюцию живых организмов. Например, автомобили в самом начале выглядели совершенно по-разному, каждый дизайнер стремился найти что-то кардинально новое, лучше, чем у других. Неудачные решения умирали, удачные решения копировались другими автомобилестроителями. Точно такое же сейчас происходит с операционными системами.
Как только ОС начали появляться, они были сильно разными, с какими-то уникальными концептами, с оригинальными интерфейсными решениями. Мышь была то однокнопочной, то трехкнопочной, то с двумя колесиками, то с одним, то с трекболом. Кнопки были квадратными, круглыми, с тенями, выпуклыми и плоскими.
Сейчас интерфейсы выровнялись и более-менее одинаковы для всех ОС. Эволюционным способом вымерли непрактичные и неудобные операционные системы, остальные адаптировались.
С мобильными системами происходит точно тоже самое. Согласитесь, что между айосом и андроиом все меньше и меньше визуальной и концептуальной разницы.
Изменения, которые добавляют какую-то функциональность всегда делают код хуже. Код становится больше, в нем появляется больше условий, ветвлений и логики. Ко всему прочему, тесты становятся более громоздкими. Обычно умные книжки советуют код рефакторить, и обкладывать дополнительными тестами, только вот совершенно непонятно когда это нужно делать, когда есть куча невыполненных задач. Ответ дали давным-давно коммунисты. Одно из правил пионеров звучит так: «оставь поляну чище, чем она была до того, как ты на нее пришел». Это правило применимо и к программированию:
Сделай код лучше, чем он был до твоих изменений. Если ты просто зашел в какой-то файлик и добавил новую функциональность, ты сделал проект хуже.
Ребята, нас уже больше пятиста человек! Ради такого события и эмоджи можно поставить. Вот оно: 🎉 (или эмоджи — это «он»?).
Я очень рад, что заметки в этом канале читают и невероятно приятно, что нас становится все больше и больше. Хотелось бы услышать пару слов и от вас тоже. Мне будет очень приятно, если вы напишете пару строк мне лично. Расскажите что вам нравится в этом канале, а что вам не нравится в канале и что стоило бы улучшить. Спасибо вам. Пишите: @aratak.
Читая различные доски объявлений о поиске работы и вакансий практически невозможно наткнуться на «оператора дрели Bosh», «установщика вентильных кран-буксовых смесителей для умывальника». Такая вот узкая специализация вообще позволительна только в тех случаях, когда совершенно точно понятно с чем нужно иметь дело. Например «адвокат по бракоразводным процессам» или «водитель маршрутного такси». И даже в этом случае даже узкая специализация говорит скорее о результате, а не об инструментах. Согласитесь, инструментарий в названии профессии выглядит как минимум странно. Конечно же это касается и вакансий. «Требуется виртуозный крутильщик руля и нажиматель педалей с опытом нажатия педалей от двух лет».
А что касается нас, айтишников, то такое встречается сплошь и рядом и, что самое ужасное, считается естесстевнным. Речь о «джаваскрипт-разработчиках» или «питон-разработчиках». Еще более серьезная степень инструментного ориентирования выражается в виде фрейморков или библиотек. «Вордпрес-разработчик», «rails-разработчик» или даже «react.js-разработчик». Гнать таких в шею. Программисты в первую очередь — решатели проблем, и что они используют для решения этих самых проблем, это дело десятое. И формулировать профессию нужно в виде проблемы, а не инструмента, который используется для этого.
В современном мире разработки невозможно существовать без трех вещей: системы контроля версий, скриптов оркестрации серверами и управлением зависимостями приложений. Это — три кита современного программирования. И только после, можно задумываться о следующем слое проблем, вроде автоматических тестов, чистоты кода, манифестов или документации.
Читать полностью…
Давайте проведем аналогию системы званий и зарплат разработчиков с военным делом. «Джуны» — это те, кто уже прошел курс молодого бойца, отслужил в армии, умеет метко стрелять и, черт побери, знает какой кусок гранаты кидать во врага, а какой оставлять в руке. Те, кто только пришли в армию в неплохой физической форме, с двумя руками и без плоскостопия — еще не солдаты, а только хотят ими быть. И после пары боевых действий такого салагу перестают считать салагой и наконец он становится «джуниором». Такому бойцу можно доверить прикрывать спину и не беспокоится за качество выполнения поставленной задачи — задача будет выполнена настолько качественным образом, насколько это только вообще возможно. Как бы банально это не прозвучало, но если вы не готовы пойти со своим коллегой в разведку, то он все еще находится за пределами градаций разработчиков.
Читать полностью…
Давайте поговорим об использовании современных смайликов в современной переписке. Эмоджи — это просто картинки по высоте соизмеримые с буквами. В определенный момент кому-то, видимо по накурке или по пьяне показалось, что символы двоеточия-тире-скобочки нужно автоматически заменять на небольшую картинку улыбающегося колобка. И понеслось. Потом их внедрили в виде отдельного набора прям в телефоны, чтобы было крайне просто вставлять их прямо в текст в любой чат с любого места. Оглянуться не успели, как эмоджи стали чем-то таким, что естественным образом воспринимается любым пользователем.
В переписке важно соблюдать некие нормы, при котором читающему ваши тексты не хотелось бы выколоть себе глаза. В переписке к современным полноцветным смайликам должны применяться все правила, которые применяются к обычным картинкам все в той же переписке. Давайте рассмотрим все случаи:
- в деловой переписке использовать категорически нельзя.
- в публичных переписках использовать нельзя.
- в личной переписке использовать можно, только крайне осторожно. Супруге можно «❤️» отправить. Или одногруппнику — «🍺».
К стикерам в чатах применимы точно те же правила, так как это все те же картинки.
Несколько эмоджи идущих подряд — моветон. Постарайтесь формулировать мысли в пределах языка, на котором общаетесь. У вас же есть такие замечательные слова, которые добавляют эмоциональную окраску вашим мыслям. Такие, как «лол», «азаза» и «ггг».
Последнее время, особенно с появлением всяких слэков, регулярно всплывает мысль о том, что мол почта умерла и те, кто пользуется почтовым протоколом для бизнес-коммуникации — безнадежно мастодонты, которые вот-вот уйдут за динозаврами. И вымирают они уже лет десять как со времен появления «Бейзкампа» («слэк», к слову говоря, изначально был содран с «Бейзкампа» чуть более, чем полностью, но об этом поговорим как-нибудь отдельно). И эти самые «мастодонты от емейлов» все никак не вымрут. Каждый раз, при выходе очередного убийственно нового и революционного инструмента общения, его создатели обещают добить наконец умирающую электропочту сокрушительным ударом. А воз и ныне там. И тому есть несколько причин:
- Проприетарность. Слэки, телеграмы, скайпы, мээс-проджекты и бейзкампы рассчитаны на полное погружение. Просто так спрыгнуть и перейти на альтернативный софт при тех же процессах невозможно. Выбрал слэк/бейзкамп — будешь платить за его использование и шансов изменить ему без потери истории и полного изменения процессов невозможно. Почта же децентрализована и каждый отдельно взятый софт легко заменяем.
- Личные предпочтения. Настроить почтовый клиент, фильтры, метки, правила обработки каждый может сам и ты и только ты контроллируешь этот процесс, и что самое важное ты контролируешь этот процесс для себя, а не для всей команды. В слэке настройки сводятся только лишь к выбору цвета, наличию аватарки и тому насколько назойливо ты будешь получать уведомления о том, что твой коллега решил написать в один из множества каналов. В более или менее крупных командах создают кучу различных каналов, называют их отдельными темами чтобы фильтровать диалоги, а потом общаются все равно в первом канале, что под руку попался. Каша и только.
- Асинхронность. Самый важный пункт, влияющий на процессы непосредственно. Чаты созданы для того, чтобы общаться в режиме вопрос-ответ и так, чтобы оба сразу были онлайн и сидели и читали сообщения друг друга. Лаг между «написал» и «прочитал ответ» иногда значительно больше минуты. Диалоги такие могут затягиваться на долгие часы. Как при этом еще успевать что-то там делать — совершенно непонятно. Особенно если хочется не отвлекаться. В почте же мысль формулируется полностью и исчерпывающе и она располагает к тому, чтобы не ждать ответа мгновенно.
Список можно продолжать, но эти три — главные тезисы убийственно неправильного подхода чатоподобных способов общения в команде. Почта не умрет никогда. Она может измениться до неузнаваемости, поменять протоколы, способы доставки, но это будет все еще почта. С открытым протоколом, распределенная и универсальная. А вот слэк умрет и его займет новый убийца почты.
Почту все ненавидят из-за двух вещей: спама и новостных рассылок. Современный спам — это не попытка заставить вам увеличить какой-нибудь орган или породниться с нигерийским принцем с наследием. Современный спам — это новостные рассылки от сервисов, где вы сами добровольно оставляете свой емейл. Каждый такой сервис считает своим долгом напоминать о себе раз в недельку в виде красиво отформатированного письма, приглашения на вебинар и каких-то там других мега-важных штуках. И это все попадает во «входящие». Отпишитесь от всего. Каждый такой сервис потребует пары кликов мышки (как правило внизу таких писем есть ссылка "unsubscribe" или просто добавьте фильтр удаления писем от этого адресата). Во «входящие» должны попадать только важные письма. Настройте фильтрацию писем, которые рассылаются важными автоматическими системами, вроде уведомлений об ошибках на продакшене или открытию нового пулл реквеста на гитхабе в отдельные подпапки, чтобы они миновали «входящие». И главная папка почтового клиента должна быть всегда пустой. И только тогда ваша рабочая почта станет полезной. А о том, почему все так любят слэк — поговорим как-нибудь отдельно.
Читать полностью…
Когда-то давным давно, каждый уважающий себя джаваскрипт-разработчик должен был написать свою собственную функцию проверки является ли объект массивом или не является. Это, к слову, было отличным вопросом на собеседовании, так как показывало достаточно глубокое понимание того, как устроены объекты и взаимоотношения между объектами в js.
Где-то, навсткидку, лет шесть-семь назад, начало необратимо и угрожающе наступать светлое будущее, в котором каждому разработчику обещали равные права на чтение файлов, прозрачное облачное хранилище над головой и адекватность интерпритатора их любимого языка. И в джаваксрипт повалили толпами. Понесли, после джикверей, бэкбоны всякие, ангулары и даже реакты. И все ради светой идеи, что сейчас можно услышать от любого джаваскриптизера, мол экмаскрипт-стодвенадцать решил все те проблемы, которые стояли перед австралопитеками, писавших на глиняных табличках пальцем по древним спецификациям на папирусе начала двухтысячных.
Но нет, дорогой читатель. Светлое будущее отменяется, ведь мы находимся все в том же болоте, выйти за которое нам не позволяет страшный монстр, который более известен в узких кругах разработчиков под ужасающим до мурашек именем «Обратная совместимость».
👆🖕🤘✋✌️☝️ вам друзья!
http://blog.jonnew.com/posts/poo-dot-length-equals-two
Весьма абстрактные рассуждения получились, но менее асбтрактно получается либо плохо либо очевидно. Заметка о взаимодействии и эффективности.
http://telegra.ph/Gvozdi-mikroskopy-i-lyubov-k-peremenam-02-23
Синтаксический сахар, соль и уксус. Часть 2.
Давайте зайдём издалека и вспомним сахар-соль в своём натуральном виде. Поедая очередной кулинарный шедевр, гурман не должен задумываться о концентрации и количестве составляющих. Он ест готовое блюдо и внутренней чакрой, третьим глазом или шестым чувством определяет нравится ли это блюдо или же не нравится. И только после этого он задумывается и анализирует свои ощущения и делает экспертные выводы вроде «соли мало» или «остро слишком». Для гурмана первичны бессознательные ощущения, а выводы и анализ вторичны. Пользователи приложений принципиально не отличаются от кулинарных экспертов. Приложение сначала им нравится или нет, а уж потом они с помощью букета ощущений и настроения пытаются понять откуда именно такие чувства к приложению.
Приготовления же блюда имеет вполне четкий алгоритм и структуру. Отклонение от норм приготовления приложения чревато тем, что в итоге получается совсем не то что задумывалось изначально по рецепту. Особенно, если повар начинает поощрять пользователей и потакать им в их прихотях. (Я сказал «приложения»? Конечно же имел в виду «блюда»!) И конечно же разумной стратегией разработчиков будет изменение приложения с выверенной точностью, создатели должны поощрять те действия пользователя, которые считаются правильными. Назовём это «интерфейсным сахаром».
В то же время, разработчики ни в коем случае не должны убирать какую-либо возможность, даже если считают ее в корне неправильной. Вместо полного удаления, такую функциональность нужно оставить как есть и не делать удобной специально. Нежелательную функциональность нужно прятать подальше, и всячески стимулировать пользователей отказываться от оной. Собственно, большинство из нас так и поступает.
Например, вместо выключения интернета по достижению лимита трафика, провайдер снижает скорость интернета до такого состояния, когда пользователь все ещё может использовать интернет, но вот торрентами или фильмами не побалуется. Или еще открытие счета в банке — процедура крайне простая и быстрая. Но вот закрытие счета, как правило, усложнено и не так прозрачно. Тем самым пользователей отталкивают от использования такой фичи, вместо полного запрета. Такой вид автоматизации назовём «интерфейсной солью».
Теперь об «интерфейсном уксусе». Будем называть интерфейсный элемент или функциональность «уксусом», если разработчики идут на поводу у пользователей и дают им то, чего хотят последние. Делают кнопки больше, ярче и мигающими, если пользователи жалуются на то, что кнопку найти тяжело. Добавляют выпадающее меню с перечислением вообще всех возможностей. Можно ещё вспомнить Генри Форда и его «более быструю лошадь» в качестве правильного поведения с сахаром и солью.
Не ведитесь на поводу у пользователей и не давайте им того, что они просят. В большинстве своем проблему локализовать значительно сложнее.
О глобальном заговоре всех разработчиков, рекрутеров и отдела продаж. О том, как отличить сеньора от миддла и почему у разработчиков в большинстве своем завышенное чувство собственной мудрости.
http://telegra.ph/V-Ispanii-vse-razrabotchiki--senory-02-01
Орфографические ошибки нейтронными сетями уже проверяют достаточно давно, а вот грамматически проверить текст — ещё та задача. В качестве входных данных были взяты комментарии на реддите, и наверно поэтому попадание достаточно низкое – ведь далеко не все реддит-комментарии грамматически верны. Все сложнее и сложнее отличать кто есть кто в интернете.
http://atpaino.com/dtc.html
Вообще все и всегда стремиться стать хаосом. Все. Всегда. Что бы вы не делали, ваш проект будет становиться все хуже и хуже. С этим сделать ничего нельзя, а можно только смириться.
Ладно, вру. Можно с этим что-то сделать, и об этом написано сто тысяч миллионов книг. Все эти книги об управлении проектами, рефакторингах, признаках чистого кода, принципах программирования как раз рассказывают о том, что делать с проектом, чтобы он не скатывался в хаос. И самое лучшее, что придумали для этого — это лишь два базовых понятия в программировании: полиморфизм и инкапсуляция. До тех пор, пока не нужно лезть внутрь библиотеки, чтобы понять как оно работает и до тех пор, пока не нужно задумываться о том, что конкретно там работает под капотом, у вас все хорошо.
Сейчас невероятно модным считается архитектура, где одно приложение состоит из множества маленьких отдельных программок, называемых микросервисами. Черт подери, это не микросервисы, это самая обычная инкапсуляция с полиморфизмом на уровне процессов и виртуализации. Если бы код в монолитном проекте был чистым и красивым, то микросервисы бы вообще не понадобились! А так микросервисная архитектура – это способ заставить разработчиков писать код с понятным и вменяемым интерфейсом взаимодействия, соблюдая вышеупомянутые принципы. Потому что в монолитном приложении за этим следить значительно сложнее.
Кстати, у эмоджи есть специальный символ хаоса, применимого к коду: «💩»
Есть офигительно красивое и умное слово, которое объясняет достаточно простую и очевидную штуку. Если нечто может быть вызвано несколько раз подряд, и это ничего не сломает и результат всегда будет один и тот же, то это нечто обладает свойством «идемпотентность». Это свойство применимо как правило к куску кода, будь то метод класса, процедура, скрипт или отправка http-запроса. Если метод класса меняет объект каждый раз, как вызывается, то он не идемпотентен. Допустим, метод увеличения числа на единицу не идемпотентен: a.increment(). А вот метод, который разрешает пользователю вход в систему, как правило, идемпотентен: user.approve().
Идемпотентность критична, когда это применимо к какому-либо независимому состоянию, например база данных или сервер. Скрипт echo 'hello' > 1.txt — идемпотентен, скрипт echo 'hello' >> 1.txt — нет. Еще одним хорошим примером важности этого свойства служат GET и POST запросы. Все, что идемпотентно может быть сделано через GET. Неидемпотентные операции делать лучше POST-подобными запросами.
В результате можно вывести правило, что ваш код должен быть идемпотентен чуть менее, чем полностью за редким исключением.
Бизнес в целом и стартаперы в частности все время говорят о клиентах-заказчиках и о необходимости делать то, что имеет большое значение для этих людей. Многие акцентируют внимание на том, что любой говнокод лучше, если он «работает и приносит вэлью». Это совершенно не так.
Поводом гордиться, что тот или иной кусок кода работает и приносит деньги — прерогатива маркетолога и отдела продаж. Для разработчика это стыд и позор.
И ещё повод гордится кодом может найтись совсем не там, где приложение его предполагает.
Недавно технократ Илон основал (или купил?) компанию, как-то там отдаленно связанную с киберпанк-будущем и об этом не написал только ленивый. Мы же давайте не будем пересказывать то, что и так попало на первые полосы всего интернета, а попробуем порассуждать на тему границы человеческой и роботизированой. Вот допустим поставил я себе титановый протез. Это я уже чуть-чуть киборг, получается? А если все зубы? А если еще и с нижней челюстью? Вроде как такими рассуждениями легко дойти до того, что личность находится в черепной коробке, а все, чем я могу управлять — это различная периферия, пусть и биологического происхождения. И сколько бы у меня не было роботизированных конечностей, подсоединенных прямо в мозг напрямую, я все еще остаюсь человеком, пока мой мозг принадлежит мне. Но это не до конца верно.
Давайте предположим, что я серьезно травмировал большой палец на левой руке. До этого я понятия не имел, что этот палец принимает участие чуть ли не во всех процессах, которые я рутинно делаю каждый день: чищу зубы, завязываю шнурки, режу хлеб. Мешать мне будет отсутствие пальца буквально пару дней, после чего я свыкнусь с отсутствием пальца и приловчусь завязывать шнурки и без его участия. Мозг подстраивается, нейронные сети в голове адаптируются. Если вдруг магическим образом переместить моё сознание в тело паука, то чувствовать себя дискомфортно я буду первую недельку. Потом же ползать и бегать на шести лапах я буду с проворством бывалого тарантула. Перемещение обратно сознания проделает тот же фокус — я буду спотыкаться о собственные ноги и пытаться мысленно нащупать у себя третью пару конечностей, но всего пару дней! Есть даже эксперимент, в котором подопытным надевали шлем с системой зеркал. В них все было видно перевернутым, и ребята так жили и занимались повседневными делами. Поначалу они ходить даже нормально не могли, спотыкаясь о собственные ноги, но в конце первой недели они легко справлялись с ездой на велосипеде, орудовали кухонным ножом и вилкой и аккуратно писали прописью.
А что будет, если подсоединить вместо руки какую-нибудь кардинально другую сложную штуковину, которая вовсе на руку и не похожа? Сможет ли человеческое сознание адаптироваться и управлять ею? Однозначно да. А что если эта штуковина вообще не будет манипулятором, а, скажем, флеш-картой с возможностью записи и чтения через нейроинтерфейс? Мозг адаптируется и начнет использовать это для запоминания какой-то там нужной мозгу информации, тем самым расширив базовые возможности мозга. Эта электронная часть мозга, в отличие от основной, перестанет стареть, будет все время выдавать тот же результат на одни и те же раздражители и вообще будет работать стабильней всего остального мозга. Свыкнувшись с новым органом, отказаться от него уже будет тяжело — это будет равносильно потере руки или глаза. Таким вот образом, постепенно мозг можно будет заменить целиком и в конце будет совершенно непонятно что есть человек и где тут робот.
Постепенным рефакторингом и плавными изменениями можно не только из обезьяны сделать человека, а еще и из человека сделать робота.
Самый бедный и несчастный вид разработчиков — это версталы. Как их, бедненьких, только не называли. «Верстальщик», «клиентский разработчик», «браузерный программист», «фронтовик», «разработчик HTML», «джаваскрипт-разработчик» (это самое обидное, на мой взгляд). Гугл вообще переводит это как «разработчик переднего конца».
Сегодня в соцсетях прочитал вообще феерическую формулировку: «Нашему клиенту на аутстафф требуется Фронт Эндщик». Фронт, мать его, Эндщик!
— Ват из йоур нейм, мистер?
— Май нейм из Эндщик. Фронт Эндщик.
Эта формулировка заиграет совсем другими красками, если любого разработчика назвать «эндщик». Попробуйте сами произнести это вслух: «биг дата эндщик», «си эндщик», «питонэндщик».
Хорошего дня, эндщики!
«Синдром мидла». Он частично пересекается с эффектом Даннинга-Крюгера. Окрепший молодой разработчик, понахватавшись знаний в различных технологиях и отраслях будет считать себя опытным экспертом, особенно если работает в достаточно большом проекте, где бюрократия и пониженная эффективность добавлена в угоду стабильности. Там, где он не принимает никаких решений, но ощущает все последствия этих решений на себе. Решения и проблемы разнообразны, но эффект у всех у них один и тот же — наш окрепший джун уверен, что он в миллион раз лучше разбирается в том, как решать проблемы проекта, которые он к большому сожалению не решает. Как управлять задачами, как покупать кофе и сколько слоев должно быть в туалетной бумаге. Какой фреймворк или библиотеку выбрать, по какой методологии правильно писать тесты и прочее и прочее. Такой разработчик всегда чем-то недоволен и у него всегда претензии.
Синдром мидла встречается повсеместно и не обязательно у новичков в отдельно взятой профессии. Лобовитые сеньоры разработчики, господа админы и мучачи дизайнеры тоже нет-нет, да и высказывают свои экспертные взгляды на вопросы, к решениям которым у них нет полномочий.
Лечится очень просто технически и достаточно трудозатратно, серией вопросов «А как надо?» и «А почему именно так?». Подавляющее большинство пациентов, страдающих таким синдромом сливаются после третьего вопроса и осознают всю тщетность бытия. Остальные, кто проходит серию испытаний логичностью и суровыми реалиями, те, которые с честью отвечают на все вопросы и докапываются до сути проблемы в состоянии что-то изменить к лучшему и без возмущений и даже полномочий.
Как правильно заниматься самолечением такого синдрома:
1. Перестать возмущаться
2. Сформулировать насущную проблему.
3. Задавать вопросы «А почему именно так?»
Не болейте!
Градация «сеньор», «мидл» и «джуниор» полностью скомпрометировала себя. Нет никаких сеньоров и джунов. Есть умные и не очень и в современной градации разработчиков тупого и опытного приравнивают к умному без опыта. Более того, в современном аду собеседований у тупого опытного больше шансов пройти собеседование и получить работу, чему у умного без опыта вообще.
Читать полностью…
Современная работа в команде должна существовать только асинхронно. Синхронные команды с условным названием «с девяти до шести» становятся все менее поворотливыми и конкурентноспособными. И ночь или день сейчас у вас или у вашего компаньона совершенно должно быть безразлично что вам, что вашему компаньону. Нынешние ноутбуки в состоянии работать часов семь без подзарядки, телефоны могут выполнять все необходимые коммуникационные функции. Мобильный интернет и вайфай-покрытие совершенно не отстают и позволяют чувствовать себя вполне комфортно в любом месте. Переключаться с «работаю» на «не работаю» нужно уметь за секунды. Создавайте собственные правила работы, ищите компромиссы со своими коллегами и не стесняйте их в выборе места и времени работы. И тогда работа будет приносить вам удовольствие.
Читать полностью…
Почему слэкоподобное общение внутри команд сейчас так популярно? Оно под стать современному интернету, где девяносто пять процентов информации — ненужный инфомационный мусор и данные, которые тебе совершенно ненужны. Человек просто учится фильтровать и пропускать мимо информацию. Важное и нужное само найдется и ответственность за получение важной информации перекладывается на плечи отправителя. Если адресат пропустил информацию в слэк-чате, то нужно ему несколько раз написать и дождаться ответа, мол «хорошо, принято». Интернет действует по такому же принципу. Одна и та же новость показывается везде, в разных ипостасях и разными способами — картинками, видосиками, текстами, инстаграммами, репостами и лайками. И слэк в этом смысле действует точно так же.
Читать полностью…
Если вы любите путешествовать и работать то у вас наверняка есть чем помочь проекту. Это обычный гугл-карта с кофейнями и коворкингами для работы. Для часто работающих в путешествиях найти приличное кафе, чтобы посидеть несколько часов за ноутом - боль.
Старбакс и Макдоналдс не особо в почете, а требования к заведениям простые - удобные столы для работы, хороший вайфай, непротивный кофе (если альтернатива есть, то вообще счастье), и хорошее отношение к людям с ноутами.
Вот карта: https://goo.gl/V2hJT5
Карту можно свободно редактировать, достаточно быть в своем гугл аккаунте. Добавьте, пожалуйста, места, в которых вы работали/работаете.
Украина на карте представлена крайне слабо и это нужно срочно исправлять. Ставьте пимпочки, затем лайки и репосты, чтобы другие тоже ставили пимпочки.
Думаю, каждый хоть раз, но оскорблял свой телефон в лице Сири, Окгугла, Кортаны или кто-там-у-вас-сегодня. Сири завела будильник с первого раза, или задала встречный раздражающий вопрос «На какой телефон позвонить? На мобильный или сотовый?». Примеров куча. А вообще можно ли так делать или нет? Достаточно философский вопрос.
https://youtu.be/DHyUYg8X31c
Превосходное эссе на тему преимущества различных концепций в программировании.
http://tonsky.livejournal.com/308320.html (пару минут чтения)
Лет двадцать назад никто не рассуждал об искусственном интеллекте, как о чем-то реальном или прикладном. В банках существовали все те же системы принятия решений. Все те же экспертные системы, что и сейчас, стоят на страже многих учреждений, будь то банки, охранные агенства или букмекерские конторы. Никто не считал их интеллектом хоть в каком-нибудь виде. Нейронные сети тоже существуют много лет, но вот называть нейронку интеллектом можно только если линейный многочлен может поработить мир или умножением матриц можно изобрести вакцину от всех болезней.
Основная задача таких экспертных систем — не пропустить отрицательный результат, будучи настолько утрами, насколько это только возможно.
Представьте себе что, вы — банк. И у вас есть задача не допустить выдачу кредита мошенникам. Написанная автоматическая система неизбежно будет давать сбои и вам нужно выбрать тот порог и выборку ложных результатов, с которой использование такой системы будет все ещё целесообразно. Понятное дело, что отказать в кредите честному заёмщику — более мелкая ошибка, чем выдача займа мошеннику. Поэтому алгоритм намеренно смещают в сторону ложных срабатываний вместо ложноотрицательных результатов.
Хотя, пилота с 80-ю задержаниями немного жаль.
https://www.theguardian.com/technology/2017/jan/27/ai-artificial-intelligence-watchdog-needed-to-prevent-discriminatory-automated-decisions
Сахар, соль и уксус в программировании.
Полвека назад был придуман термин «синтаксический сахар», который я уверен не нуждается в каком-либо дополнительном представлении. Только вот изначально термин представлял собой нечто такое, что никак не изменяло базовый набор возможностей, а только лишь упрощал работу. Допустим, конструкция +=, вместо обычного a = a + x. Синтаксическая соль, как настоящий антагонист, должен был усложнять жизнь разработчикам в тех местах, где легко ошибиться. Самая простая демонстрация соленого правила написания — обязательная точка с запятой в конце каждой операции. Считалось, что таким образом разработчик будет допускать значительно меньше авто-ошибок.
Позже, совершенно естественным образом, синтаксически сладкие конструкции стали использоваться значительно чаще своих натуралов и стали неким стандартом написания. Синтаксическая соль также эволюционировала и превратилась просто в отсутствие сахара. Как пример, точка с запятой стала необязательной, но писать принуждали обязательно в разных строчках. Вышло, что разработчик все еще защищен от нежелательного поведения, но синтаксис уже не так сильно напрягает. В таком вот окружении сахар концентрировался все сильней и сильней и закреплялся в языках. С годами такой вот концентрированный сахар превращается не в мёд, а в уксус. Конструкции, написанные с применением таких практик, становились плохо читаемыми и неочевидными. Правило наличия синтаксического уксуса не так просто сформулировать, поэтому грань между слишком сладким и уксусным понять можно разве что интуитивно.
Сахар и соль — не две противоположности, а ортогональные понятия. Соль в слабой концентрации значительно полезней сахара в больших количествах. И «синтаксический уксус» — гиперболизация сахара, а не соли.
Делимся хорошими репозиториями.
Джаваскрипт не является самым-самым языком вселенной и все такое, хотя в нескольких номинациях он безусловный лидер. Одна из таких вот номинаций — «самый неоднозначный язык». В ней джаваскрипт на несколько корпусов оторвался от всех остальных.
В этом репозитории собрали огромное количество примеров хорошего и плохого использования синтаксиса и возможностей джаваксрипта. По своей сути это адаптация принципов, описанных в книге «Чистый код» для джаваскрипта. И как утверждают авторы, это вовсе не гид по стилям написания кода.
https://github.com/ryanmcdermott/clean-code-javascript