Экстраполяция IT
2.46K subscribers
89 photos
25 videos
305 links
Канал об IT в целом и о программировании в частности.

На канале объявлено военное положение и поэтому по вопросам рекламы пишите: @aratak, а деньги отправляйте сюда: https://send.monobank.ua/jar/97f7LwGQJF
加入频道
Немного о экзотических способах программирования. Мы с вами давно привыкли, что настоящие языки программирования должны записываться буквами и быть похожими на коверканный английский язык. А вот вам язык программирования, который в первую очередь графический. Да-да! И этот язык отличается от всех прочих графических языков программирования тем, что им реально пользуются. И не где-нибудь в шестом классе сельской школы, а в космической отрасли! Конечно, ракеты с помощью такого языка не запускают, но выбор инструмента интересный. Я вот не нашел как они на нем тесты пишут. Пишут ли вообще они тесты или сразу в продакшен?

http://drakon-editor.sourceforge.net/
Сегодня поговорим об эпохе микросервисов.

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

А последние пару лет эволюция микросервисов взяла новую веху своего развития. Теперь микросервисы живут отдельными приложениями где-то там, в интернете. И разрабатываемое приложение использует API-приложения третьих лиц для решения своих проблем. И речь даже не о сервисе сохранения фотографий в облаке Амазона и не о нейросетях-как-сервис -- тут-то понятны мотивы и способы монетизации. Речь об обычной функциональности, которую раньше писали сами и мысли не было платить за это, как за отдельный сервис. Сервис определения города по IP-адресу, сервис по отправке емейлов через API, сервис по индексации страниц, сервис по генерации фавиконки… Тысячи их!
И никакого вывода из вышеперечисленного не будет. Можно было бы посоветовать взвешивать риски использования сторонних продуктов, но вы же и так это делаете. А в качестве компенсации отсуствия выводов — ссылка на «awesome» список сервисов, с бесплатным доступом: https://github.com/ripienaar/free-for-dev

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

В теории игр есть такой термин с поэтическим названием «Проклятье победителя». Это разочарование, которое испытывают люди после покупки неоправдано дорогой вещи. Конечно, чаще всего это связано с аукционами или фондовыми биржами, но красивые примеры запомнить проще. Допустим, Остапа Бендера и Кису Воробьянинова это самое проклятие прямо-таки преследовало. Или молодоженов оно настигает через годик после поспешной свадьбы, когда все оказывается не так романтично как до женитьбы.
Такое вот проклятье схлопотать можно по двум причинам -- нехватка информации и соревновательный дух. Всегда убеждайтесь, что новый макбук в действительности стоит того, чтобы купить его вообще и ни в коем случае не стремитесь купить его первым.
В полку джаваскриптовых сборщиков прибыло. В этот раз -- библиотека от фейсбуков. Горшочек, не вари.
https://yarnpkg.com/
Современная «Олимпиада» перестает быть тем собранием спортсменов, которые демонстрируют свои достижения. Уже давным-давно олимпийцы разбились на группы по стране проживания и на Олимпиаде сейчас скорее демонстрируется поддержка и финансирование спортсменов государством, чем действительно труд, упорство и сила отдельных спортсменов. Кроме того, крайне тяжело найти современного олимпиадника, который вообще не употребляет никакой допинг (кёрлинг, наверное, не в счет). Вопрос в том, что старые допинги уже распознали и запретили, некоторые допинги проверили и разрешили, и вот задача фармацевтических предприятий разных стран состоит в том, чтобы найти такой препарат, который улучшает показатели спортсмена, но за допинг не считается и в крови/моче не находится. Современную олимпиаду вполне можно назвать «соревнованием фармацевтов разных государств», и если относиться к этому с этой точки зрения, многое становится на свои места. Уже давно пора разрешить любые виды допинга и смотреть олимпиаду на совсем другом уровне.

Меня, как большого любителя разнообразных игр, всегда возмущал тот факт, что компьютерные игры в большинстве своем совсем не рассчитаны на работу с внешними сервисами. Это в том смысле, что нельзя написать такого бота к игре, (скажем, к «Квейку» или «Контр-Страйку») который бы работал на отдельном сервере и общался с игрой не посредством манипуляциями с игровыми объектами внутри игры (как сейчас делают почти все боты), а с помощью специального API, рассчитанного в главным образом на ботов. Конечно же, игры, которые технически вовсе не игры и больше похожи на интерактивный фильм, чем на игру, тут не в счет. Этих вот «Нажмите-Е-чтобы-выиграть» игр кругом пруд пруди, и к ним эта мечта не относится. Более интересны игры, которые попадают в разряд киберспорта.
И с такими вот возможностями наверняка появятся бото-спортивные соревнования по киберспортивным играм, где участники будут не корейцы, виртуозно владеющие мышью и клавиатурой, а боты и отдельные команды программистов, обслуживающие этих вот ботов.

Компания «Близард» вот делает серьезный шаг в эту сторону. «Старкрафт» — это вам не «Го». https://deepmind.com/blog/deepmind-and-blizzard-release-starcraft-ii-ai-research-environment/

Хороших выходных!
Свершившаяся пятница и грядущие выходные не должны помешать нам самообразовываться и сегодня будут две ссылки по этому поводу. Это две публикации связанных с лямбда-исчисленем. Одна статья 1980, вторая — 1984 года выпуска, так что «новостями» эти ссылки назвать нельзя, хотя полезность их значительно выше поточных новостей из лент различных публичных групп.
Одна из них — короткая вводная в лямбда-исчисление, вторая — эссе на тему полезности функционального программирования.

http://www.cs.bham.ac.uk/~axj/pub/papers/lambda-calculus.pdf
http://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf

Хороших выходных!
Профессия «программист» постепенно перестает быть элитной и превращается в обычную сферу обслуживания, вроде сантехника или юриста. На собеседование идут люди, которые далеки не только от процесса построения приложений, но и вообще от возможности аналитически мыслить. В итоге дефицит умных людей в профессии порождает дефицит кадров. Мало мальски адекватный человек, который все еще далек от теоретических знаний программирования и умеет контроллеры со вьюхами правильно именовать и проработав два года в профессии становится сеньором начинает диктовать свои условия работы, потому как уже приносит прибыль компании. Отсюда и попытки различных компаний покупать теннисные столы, нанимать массажисток, покупать иксбоксы и устраивать кальяные в офисах. Совершенно все равно что знает и как мыслит разработчик — главным становится извлечение прибыли.

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

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

Хорошего вечера!
Делимся хорошими репозиториями.

Джаваскрипт не является самым-самым языком вселенной и все такое, хотя в нескольких номинациях он безусловный лидер. Одна из таких вот номинаций — «самый неоднозначный язык». В ней джаваскрипт на несколько корпусов оторвался от всех остальных.

В этом репозитории собрали огромное количество примеров хорошего и плохого использования синтаксиса и возможностей джаваксрипта. По своей сути это адаптация принципов, описанных в книге «Чистый код» для джаваскрипта. И как утверждают авторы, это вовсе не гид по стилям написания кода.

https://github.com/ryanmcdermott/clean-code-javascript
Орфографические ошибки нейтронными сетями уже проверяют достаточно давно, а вот грамматически проверить текст — ещё та задача. В качестве входных данных были взяты комментарии на реддите, и наверно поэтому попадание достаточно низкое – ведь далеко не все реддит-комментарии грамматически верны. Все сложнее и сложнее отличать кто есть кто в интернете.

http://atpaino.com/dtc.html
Сахар, соль и уксус в программировании.

Полвека назад был придуман термин «синтаксический сахар», который я уверен не нуждается в каком-либо дополнительном представлении. Только вот изначально термин представлял собой нечто такое, что никак не изменяло базовый набор возможностей, а только лишь упрощал работу. Допустим, конструкция +=, вместо обычного a = a + x. Синтаксическая соль, как настоящий антагонист, должен был усложнять жизнь разработчикам в тех местах, где легко ошибиться. Самая простая демонстрация соленого правила написания — обязательная точка с запятой в конце каждой операции. Считалось, что таким образом разработчик будет допускать значительно меньше авто-ошибок.

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

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

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

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

https://www.theguardian.com/technology/2017/jan/27/ai-artificial-intelligence-watchdog-needed-to-prevent-discriminatory-automated-decisions
Синтаксический сахар, соль и уксус. Часть 2.

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

Приготовления же блюда имеет вполне четкий алгоритм и структуру. Отклонение от норм приготовления приложения чревато тем, что в итоге получается совсем не то что задумывалось изначально по рецепту. Особенно, если повар начинает поощрять пользователей и потакать им в их прихотях. (Я сказал «приложения»? Конечно же имел в виду «блюда»!) И конечно же разумной стратегией разработчиков будет изменение приложения с выверенной точностью, создатели должны поощрять те действия пользователя, которые считаются правильными. Назовём это «интерфейсным сахаром».

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

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

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

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

https://youtu.be/DHyUYg8X31c
Когда-то давным давно, каждый уважающий себя джаваскрипт-разработчик должен был написать свою собственную функцию проверки является ли объект массивом или не является. Это, к слову, было отличным вопросом на собеседовании, так как показывало достаточно глубокое понимание того, как устроены объекты и взаимоотношения между объектами в js.

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

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

👆🖕🤘✌️☝️ вам друзья!

http://blog.jonnew.com/posts/poo-dot-length-equals-two
Если вы любите путешествовать и работать то у вас наверняка есть чем помочь проекту. Это обычный гугл-карта с кофейнями и коворкингами для работы. Для часто работающих в путешествиях найти приличное кафе, чтобы посидеть несколько часов за ноутом - боль.

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

Вот карта: https://goo.gl/V2hJT5

Карту можно свободно редактировать, достаточно быть в своем гугл аккаунте. Добавьте, пожалуйста, места, в которых вы работали/работаете.

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