2631
Канал об IT в целом и о программировании в частности. На канале объявлено военное положение и поэтому по вопросам рекламы пишите: @aratak, а деньги отправляйте сюда: https://send.monobank.ua/jar/97f7LwGQJF
Доброго утра, друзья! На новогодние праздники получилось собрать всю волю в кулак и сформулировать мысли об эволюционном подходе к разработке продуктов.
http://telegra.ph/Эволюция-и-аджайл-01-03
Свершившаяся пятница и грядущие выходные не должны помешать нам самообразовываться и сегодня будут две ссылки по этому поводу. Это две публикации связанных с лямбда-исчисленем. Одна статья 1980, вторая — 1984 года выпуска, так что «новостями» эти ссылки назвать нельзя, хотя полезность их значительно выше поточных новостей из лент различных публичных групп.
Одна из них — короткая вводная в лямбда-исчисление, вторая — эссе на тему полезности функционального программирования.
http://www.cs.bham.ac.uk/~axj/pub/papers/lambda-calculus.pdf
http://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf
Хороших выходных!
Современная «Олимпиада» перестает быть тем собранием спортсменов, которые демонстрируют свои достижения. Уже давным-давно олимпийцы разбились на группы по стране проживания и на Олимпиаде сейчас скорее демонстрируется поддержка и финансирование спортсменов государством, чем действительно труд, упорство и сила отдельных спортсменов. Кроме того, крайне тяжело найти современного олимпиадника, который вообще не употребляет никакой допинг (кёрлинг, наверное, не в счет). Вопрос в том, что старые допинги уже распознали и запретили, некоторые допинги проверили и разрешили, и вот задача фармацевтических предприятий разных стран состоит в том, чтобы найти такой препарат, который улучшает показатели спортсмена, но за допинг не считается и в крови/моче не находится. Современную олимпиаду вполне можно назвать «соревнованием фармацевтов разных государств», и если относиться к этому с этой точки зрения, многое становится на свои места. Уже давно пора разрешить любые виды допинга и смотреть олимпиаду на совсем другом уровне.
Меня, как большого любителя разнообразных игр, всегда возмущал тот факт, что компьютерные игры в большинстве своем совсем не рассчитаны на работу с внешними сервисами. Это в том смысле, что нельзя написать такого бота к игре, (скажем, к «Квейку» или «Контр-Страйку») который бы работал на отдельном сервере и общался с игрой не посредством манипуляциями с игровыми объектами внутри игры (как сейчас делают почти все боты), а с помощью специального API, рассчитанного в главным образом на ботов. Конечно же, игры, которые технически вовсе не игры и больше похожи на интерактивный фильм, чем на игру, тут не в счет. Этих вот «Нажмите-Е-чтобы-выиграть» игр кругом пруд пруди, и к ним эта мечта не относится. Более интересны игры, которые попадают в разряд киберспорта.
И с такими вот возможностями наверняка появятся бото-спортивные соревнования по киберспортивным играм, где участники будут не корейцы, виртуозно владеющие мышью и клавиатурой, а боты и отдельные команды программистов, обслуживающие этих вот ботов.
Компания «Близард» вот делает серьезный шаг в эту сторону. «Старкрафт» — это вам не «Го». https://deepmind.com/blog/deepmind-and-blizzard-release-starcraft-ii-ai-research-environment/
Хороших выходных!
Что-то недавняя презентация о новых версиях ноутбуков от компании «Эппл» прошла уж пару дней как, а разговоров о ней все так же много. Наш канал решил не отставать от тренда, но со свойственной ему эпистолярностью и высокопарным слогом.
В теории игр есть такой термин с поэтическим названием «Проклятье победителя». Это разочарование, которое испытывают люди после покупки неоправдано дорогой вещи. Конечно, чаще всего это связано с аукционами или фондовыми биржами, но красивые примеры запомнить проще. Допустим, Остапа Бендера и Кису Воробьянинова это самое проклятие прямо-таки преследовало. Или молодоженов оно настигает через годик после поспешной свадьбы, когда все оказывается не так романтично как до женитьбы.
Такое вот проклятье схлопотать можно по двум причинам -- нехватка информации и соревновательный дух. Всегда убеждайтесь, что новый макбук в действительности стоит того, чтобы купить его вообще и ни в коем случае не стремитесь купить его первым.
Немного о экзотических способах программирования. Мы с вами давно привыкли, что настоящие языки программирования должны записываться буквами и быть похожими на коверканный английский язык. А вот вам язык программирования, который в первую очередь графический. Да-да! И этот язык отличается от всех прочих графических языков программирования тем, что им реально пользуются. И не где-нибудь в шестом классе сельской школы, а в космической отрасли! Конечно, ракеты с помощью такого языка не запускают, но выбор инструмента интересный. Я вот не нашел как они на нем тесты пишут. Пишут ли вообще они тесты или сразу в продакшен?
http://drakon-editor.sourceforge.net/
Недавно услышал термин, который подходит некоторым разработчиком куда лучше общепринятого. Старый общепринятый термин — «full stack developer» и подразумевает он тот факт, что разработчик прекрасно чувствует себя, правя html с css и оптимизируя sql-запросы. Термин этот появился достаточно давно — в те времена, когда кроме css и простенького js с клиентской стороны не было и быть не могло. А на сервере в те времена были PHP-скрипты, которые даже с натяжкой сложными называть было нельзя. В те счастливые времена найти разработчика, разбирающегося «с этими вашими красотами в браузере» и понимающего что такое индексы в базе данных было непросто и такие разработчики весьма ценились.
Сейчас же сложность работы с каждой отдельной частью веб-приложения значительно выше. Нет, я не хочу сказать, что разработчики в те времена не могли сделать что-нибудь сложное или сложно-абстрактное. Тогда сложные программы были, но они были не в вебе и о термине «full stack developer» никто даже не заикался. Сейчас же веб-приложение превратилось в Франкенштейна, где каждая отдельная запчасть стоит отдельного внимания и отдельных навыков. И термин «фулстековый разработчик» превратилось скорее в ругательство, чем в похвалу. Мол, разработчик одинаково плохо разбирается во всех технологиях и недостаточно усидчив, чтобы хорошо освоить хотя бы одну из них.
Новый термин — «hybrid developer» и подразумевает он, что разработчика можно попросить и спеть и сплясать. Такие разработчики, как гибридные автомобили — вроде бы и электрокары, но все еще с выхлопными газами и значительно дороже обычных разработчиков. Только не подумайте, что это обидный термин, вовсе нет! Гибридный автомобиль в состоянии проехать 1500 километров без дополнительной зарядки/заправки, что невозможно сделать ни на ДВС ни на батареях по отдельности. В общем, честь вам и хвала, друзья-гибдидные разработчики.
Помню, как играл в детстве в Супер Марио и все в этой игре было прекрасно. Ах, какая была графика, какие звуки, какой геймплей! Позже узнал, что облачка и кусты на фоне — это один и тот же объект, программно покрашенный в разные цвета. Какой это был удар! И когда в мой мир пришли тайлы и спрайты, «Супер Марио» был морально оправдан за такое нечестное издевательство над моим разумом. Десять-пятнадцать лет назад спрайты и тайлы в интернете были нормальным делом, и каждый второй сайт считал просто обязательным найти такой узор, которым можно замостить фон и чтобы паттерн картинки не угадывался. Это было сделать довольно сложно, особенно если фоновый спрайт был каким-то осознанным, допустим бело-голубые облака или селено-салатовая трава. Как только вы замечаете какую-то особенность в фоне, например маленький сучок в древесном волокне, который повторяется через одинаковые интервалы, то сразу теряется вся иллюзия натуральной случайности.
Семь лет назад появилось «правило цикады» (https://habrahabr.ru/post/117160/) для формирования бесшовных заливок и это было гениально. Это было невероятно просто, решение лежало на поверхности и от этого оно становилось еще гениальней — природа и математика подсказали решение рисования заливок на веб-страничках!
Проблема цикад была в том, что повторяющийся паттерн минимизировался, но не исчезал. Чтобы нарисовать полностью неповторяющийся паттерн, нужен интеллект или хотя бы его эмуляция. И тут на сцену выходят нейронные сети, которые от рисования картин Рембрандта и генерации художественных произведений и песен переходят в более практическое русло. На вход программе подается небольшой пример картинки, которой нужно замостить фон, а она уже генерирует неповторяющийся фон. Создатель библиотеки пошел дальше и добавил третье измерение в своих фонах и получил вполне правдоподобный лабиринт из нескольких шаблонных картинок. По-моему, это прекрасно.
https://github.com/mxgmn/WaveFunctionCollapse
Чем клево число Пи? Во-первых и основных это иррациональность и трансцендентность этого числа. Технически это означает, что π нельзя представить никаким другим числом. В том смысле, что его нельзя предствить в виде корня какого-то другого многочлена с целыми коэффициентами и нельзя представить в виде дроби простых чисел (m/n). Число π бесконечно и непериодично в десятичном представлении. А это значит, что теоретически в числе π найдется любая другая подпоследовательность. Нужно только хорошо ее поискать.
А совсем недавно нашли формулу, которая позволяет вычислять любой знак числа пи без вычисления предыдущих, и эта формула относительно проста. И тут понеслось.
Раз мы знаем, что в числе π спрятана любая последовательность чисел и по указанному смещению и длине мы с легкостью можем вычислить эту подпоследовательность, то можно «спрятать» в числе π любой файл, программу или секретный код, главное, чтобы он выражался через числовую последовательность. В итоге в числе π уже есть «Война и мир», исходный код всех операционных систем, все фотографии, которые все человечество когда-либо сделало или сделает. Нужно просто хорошенечко поискать.
Конечно же, искать подпоследовательность хотя бы в 50 мегабайт очень долго и тяжело, но вот после того, как найти такую подпоследовательность, этот файл можно выписать себе на листик в виде смещения в π и длинне подпоследовательности. Сжатие в 100%! Никаким «зипам» и «рарам» это и не снилось!
К сожалению не все так радужно, как хотелось бы. И дело не в том, что такую подпоследовательность очень долго искать -- закон Мура говорит нам, что искать таки можно и в будущем будет это легко. Дело в том, что такое смещение вполне вероятно будет занимать больше места, чем сам файл.
Ну ничего, давайте файл разобъем на более мелкие кусочки, скажем в 640 килобайт, а их уже будем прятать в π. Тогда на смещение в 640КиБ нам нужно будет потратить, скажем, 2Киб, и тогда сжатие будет не 100%, а ~99%. Звучит более реалистично и вполне реализуемо. Более того, уже даже файловая система такая есть, основанная на этом незамысловатом принципе. Работает, конечно, медленно, но работает.
https://github.com/philipl/pifs
Продолжая тему awesome-репозиториев хочется отметить репозиторий с собранием публикаций, статей и книг так или иначе связанный с машинным обучением и нейтронными сетями. Многие из которых нужно прям брать и читать.
https://github.com/terryum/awesome-deep-learning-papers
Многие наверняка слышали про некие «проблемы тысячилетия» и про самую известную проблему, которая называется «P и NP». Наверняка столь популярный успех и узнаваемость этой проблемы как-то связана с тем, что это единственная проблема, после прочтения стати на википедии понятно хотя бы о чем речь.
Если объяснять на пальцах, то бывает два вида задач. Как бы видов задач больше, но интересуют нас сейчас только два.
Первый вид задач -- это те задачи, решить которые можно не угадывая ответ. Например задача «найти ответ выражения 2 + 3» — задача класса «P», ведь не обязательно перебирать все натуральные числа, чтобы найти ответ. Второй вид задач решается только полным перебором или подбором. Строго говоря, существование задач, которые можно решить полным перебором и нельзя решить быстрее еще не доказано. Допустим, знаменитая задача коммивояжера точно относится к классу «NP» и является ярким его представителем. Или задача раскраски планарного графа и раскраской его тремя цветами.
Сложность этой проблемы тысячилетия состоит как раз в том, чтобы найти способ решить задачу класса «NP» быстрее, чем полным перебором. Или же доказать, что это не возможно.
Какова вероятность, что в группе из 23 человек найдутся двое с днями рождения в один и тот же день в году? Интуиция подсказывает, что вероятность будет весьма небольшая. В самом деле, вспомните свою группу из института или класс из школы. Вероятность совпадения дней рождения двух человек с любым днём в году равна 0.27% (1/365). При группе в 23 человека, умножаем эту вероятность на 23 и получаем всего лишь 6.3%. Для 60 человек умножение даст 16,2%.
Такое рассуждение в корне не верно, так как нужно оценивать не общее количество людей, а общее количество пар людей в группе. При группе в 23 человека таких пар будет 253, а в группе из 60 людей пар будет 1770. В итоге для группы из 60 человек такая вероятность будет более 99%, а для группу в 23 человека вероятность будет больше 50%. Сначала такое утверждение звучит невероятно, но если правильно считать все кажется логичным и последовательным. Для этой задачи есть даже специальное название, «Парадокс дней рождения», но строго говоря, парадоксом это является только из-за различия в интуитивном восприятии и результатами математического расчета.
Вместо вывода можно посоветовать проверять гиппотезы, прежде чем брать за основу решение, которое лишь выглядит очевидным, а таковым не является.
Никто не знает какая сингулярность нас ждет. Возможно, человечество никогда не придумает исскусственный интеллект, а просто возьмет количеством фонннеймановского кода. Вполне вероятно, что те абстракции, что сейчас не позволяют подняться на следующую ступень программирования и оперировать сложными макро-командами возьмут верх над квантовыми вычислениями и тщетными попытками смоделировать мозг. Сейчас проходит соревнования роботов, в котором роботам-участникам предлагается много чего такого делать, чего ждут все фантасты. И по скромной оценке экспертов, модели роботов на этом конкурсе года имеют интеллект примерно трехлетнего ребёнка. Да-да, вы ничего не перепутали. Трехлетнего. И, конечно же, такое сравнение просто-напросто спекуляция. Они, конечно, делают все действия, на уровне ребенка, но их интеллект не сравним ни с одним живым существом, потому как они не имеют возможности обучаться и адаптироваться. Тем не менее, одно из возможных сингулярностей будет состоять из множества тьюринг-полных конечных автоматов. Хотя, как представить себе саморазвивающийся конечный автомат понятия не имею.
Читать полностью…
"-Что там с тикетом, Чарли?
- Пять часов, Турецкий
- Пять часов назад было же два часа."
Все, что вы боялись спросить о функциональном программировании, но боялись спросить собрано в одном справочнике.
https://github.com/hemanth/functional-programming-jargon
Сегодня последний день, когда вы можете бесплатно обновить Windows 7/8/8.1 до Windows 10. С завтрашнего дня бесплатно можно будет обновиться только до Ubuntu.
Читать полностью…
Профессия «программист» постепенно перестает быть элитной и превращается в обычную сферу обслуживания, вроде сантехника или юриста. На собеседование идут люди, которые далеки не только от процесса построения приложений, но и вообще от возможности аналитически мыслить. В итоге дефицит умных людей в профессии порождает дефицит кадров. Мало мальски адекватный человек, который все еще далек от теоретических знаний программирования и умеет контроллеры со вьюхами правильно именовать и проработав два года в профессии становится сеньором начинает диктовать свои условия работы, потому как уже приносит прибыль компании. Отсюда и попытки различных компаний покупать теннисные столы, нанимать массажисток, покупать иксбоксы и устраивать кальяные в офисах. Совершенно все равно что знает и как мыслит разработчик — главным становится извлечение прибыли.
Компаниям советовать ничего не нужно — адекватные все и так знают, остальные советов не слушают. Честь и хвала компаниям, которые выставляют адекватные требования к программистам, критически подходят к процессу найма новых сотрудников и не стесняются расставаться с сотрудниками, которые вроде бы и приносят прибыль компании, но не в состоянии приносить пользу.
Разработчикам в первую очередь можно посоветовать ориентироваться не на соцпакет, сорта кофе и диагональ мониторов, а на будущих сотрудников. Они должны быть умнее вас и могли бы вас чему-нибудь научить. Собеседование, на котором вы не узнали ничего нового отражает будущее работы в данной компании. Собеседование в первую очередь — диалог, а не допрос. На опыте собеседований не было ни разу такого, чтобы собеседуемый попросил рассказать о будущих сотрудниках или показать код, который пишут его будущие коллеги.
Хорошего вечера!
Привет. Давненько небыло никаких публикаций в этот канал. Исправляемся и сразу новым модным способом — через «телегра.ф». Поговорим о синдроме выбора арбуза.
http://telegra.ph/%D0%9A%D0%B0%D0%BA-%D0%B2%D1%8B%D0%B1%D0%B8%D1%80%D0%B0%D1%82%D1%8C-%D0%B0%D1%80%D0%B1%D1%83%D0%B7%D1%8B-11-25
В полку джаваскриптовых сборщиков прибыло. В этот раз -- библиотека от фейсбуков. Горшочек, не вари.
https://yarnpkg.com/
Сегодня поговорим об эпохе микросервисов.
Микросервисы, как понятие утвердилось недавно по отношению к изобретению пороха или, скажем, по отношению к открытию Америки, но это было ужасно давно по меркам интернета — cобственно, всего-то четыре года назад. Давно, правда? Но сейчас уже всем даже тошнит от любого предложения так или иначе связанного с микросервисами. В домикросервисные времена большие системы тоже масштабировались и разносились на разные сервера. Отдельные части приложения обосабливались и выделялись в отдельное независимые приложения. Только вот раньше этот способ разрабатывать приложения считался обычной эволюцией приложения, а сейчас это микросервисы и архитектуру приложения многие ошибочно начинают с планировки микросервисов. На волне работы с микросервисами многие команды поддались тренду и начали распиливать свои приложения на отдельные независимые части, что лишь усложнило дальнейшую разработку. Например, команда gitlab сначала предприняла попытку вычленить свой сервис непрерывного тестирования в отдельный «микросервис», но вовремя поняв свою ошибку объединила два отдельных приложения назад в одно. И стало только лучше.
А последние пару лет эволюция микросервисов взяла новую веху своего развития. Теперь микросервисы живут отдельными приложениями где-то там, в интернете. И разрабатываемое приложение использует API-приложения третьих лиц для решения своих проблем. И речь даже не о сервисе сохранения фотографий в облаке Амазона и не о нейросетях-как-сервис -- тут-то понятны мотивы и способы монетизации. Речь об обычной функциональности, которую раньше писали сами и мысли не было платить за это, как за отдельный сервис. Сервис определения города по IP-адресу, сервис по отправке емейлов через API, сервис по индексации страниц, сервис по генерации фавиконки… Тысячи их!
И никакого вывода из вышеперечисленного не будет. Можно было бы посоветовать взвешивать риски использования сторонних продуктов, но вы же и так это делаете. А в качестве компенсации отсуствия выводов — ссылка на «awesome» список сервисов, с бесплатным доступом: https://github.com/ripienaar/free-for-dev
Продуктивного дня!
В шестом классе я перестал вести школьный дневник. Да, тот дневник, где нужно было записывать домашнее задание и ставить оценки для родителей и в котором были оценки за ведение дневника. И ни один учитель не смог убедить меня в том, что ведение дневника полезно. Три стандартных вопроса, которые они задавали: «Как узнают родители об оценках?», «как ты записываешь домашнее задание?» и «Где учителям ставить отметки о моем плохом поведении?». Домашнее задание я прекрасно запоминал и был предельно честен со своими родителями: если их вызывали в школу — я им об этом говорил, если я схлопотал тройку по биологии — они узнавали об этом в тот же день. В конце седьмого класса учителя смирились. Домашние задания выполнялись, родители были в курсе об успеваемости и поведении и знали о том, что оценка ведения дневника у меня «2». Ведение дневника — это хороший способ коммуницировать в распределенной команде «учитель-ученики-родители» и хороший способ для учителей унифицировать работу со всеми учениками и их родителями. Но совершенно неэффективный способ работать с точки зрения самого ученика.
А сейчас одна из самых сложных задач для программистов — планирование и оценивание предстоящих работ. Над решением этой проблемы бились многие айтишники и до сих пор придумывают для нас различные своды законов и правил, по которым нам нужно жить и работать. И еще называют их всякими красивыми названиями вроде «канбан», «аджайл», «скрам» или что там еще модно. Все они делают по сути одно и тоже, только слегка разными способами — пытаются систематизировать и обобщить правила работы с любыми проблемами, которые возникают в процессе работы. И самая большая беда всех этих способов — это то, что эффективный способ сделать ту или иную работу отметается в пользу унификации и универсализации любых работ. Лучше сделать задачу по писанному своду правил, а не самым эффективным способом. Конечно же, в этом есть свои плюсы, если смотреть на это с позиции менеджера или управляющего компании. Но вот тот исполнитель, которому приходится с этим работать, видит в таких системах сплошные минусы.
Нет универсального алгоритма работы с задачами для любого коллектива. Любая методология, которая неплохо работает на группе в 15 человек совершенно не будет работать на группе в 150 человек. А методология работы с коллективами в тысячи людей совершенно не подходит для небольшой аутсорс-фирмы в 40 человек. Глупо следовать трендам, приглашать «скрам-коуч мастера» потому что я не умею работать по этой методологии и использовать трелло, потому, что у кого-то это работает, а значит у нас тоже заработает. А любой инструмент или методология не должны ломать уже работающие процессы. Вместо этого они должны лишь описывать то, что и так уже происходит.
Выбирайте инструменты под задачи, а не подстраивайте задачи под инструмент. Удачных выходных!
Давайте поговорим об локальном и глобальном экстремуме.
Наверняка многие из вас помнят этот термин из школьно-институтского курса, но я все равно напомню. Экстремум — эта такая штука, которая показывает максимальное значение функции в каком-то интервале. Если говорить об экстремуме функции, и если нарисовать функцию с помощью графика, то визуально экстремум найти очень просто. А вот если нужно найти экстремум в чем-то таком, которое нарисовать сложно и вообще понять где там параметры, то сделать это крайне нетривиально.
Допустим, нужно найти идеальный алкогольный напиток. И есть такой вот нехитрый способ. Берем совершенно любой напиток и начинаем потихоньку его улучшать. С каждым новым улучшением мы приближаемся к идеальному напитку и будем делать это до тех пор, пока любое изменение продукта не будет приводить к его ухудшению. Когда мы достигнем такого состояния, мы по идее должны получить идеальный напиток. Все хорошо, только мы таким способом получаем локальный экстремум, а не глобальный. А вот глобальный экстремум найти таким способом гарантировано не получится.
Вот пиво, как напиток, появилось очень давно (V век до нашей эры) и служило с одной целью — получить алкогольный напиток хоть каким-нибудь способом. Пиво горькое, невкусное, но голову кружит и язык развязывает. Поэтому пиво начали закусывать всякими сильнодействующими закусками с ярко выраженным вкусом, допустим рыбой. Таким образом пиво хоть как-то можно было пить, хоть немного забив его горький вкус. Позже получили способ достигать алкогольного опьянения более эффективно, но пиво, как напиток осталось. Время шло, пиво варили все лучше и лучше, закуски находили все изысканней и хитрее. Пиво, как пиво сейчас уже тяжело улучшить, хотя идеальным этот напиток назвать нельзя. Более того, за последние десятилетия появилось безалкогольное пиво! Безалкогольное, ребята! То, ради чего пиво, собственно, создавалось, сейчас безбожно убрали из этого напитка, оставив все то, за что пиво ненавидели последние семь тысяч лет — горький вкус и неприятное послевкусие. Путем постепенных улучшений и маленькими шагами человечество получило горький невкусный безалкогольный напиток из напитка, целю которого изначально был алкоголь. Если бы человечество стремилось получить идеальный напиток, то безалкогольное пиво, да и вообще пиво не появилось бы вообще или бы кануло в лету.
Теперь поговорим об разработке проектов. Сейчас преобладающим способом разработать любое приложение является аджайл-методология в том или ином виде. А этот способ работать над проектом предполагает какой-то минимально работающий проект, скажем, первым попавшимся способом. И потом постепенно маленькими шагами развивать систему, чтобы после каждого улучшения система становилась все лучше и лучше. Уже видна аналогия? Минимально работающий продукт (MVP) — это то самое горькое пиво, которое нужно пользователям из-за какого-то набора функций (в нашей аналогии — алкоголя). Постепенное улучшение такого продукта рано или поздно сделает из него безалкогольное пиво, хотя пользователям нужен алкоголь!
Вместо выводов можно предложить подумать над алгоритмом получения идеального алкогольного или безалкогольного напитка. Ну или стратегией развития продукта, чтобы получить идеальный продукт, тут уж вам видней какую абстракцию легче представлять.
На нейронных сетях и машинном обучении мир не сходится. Существует множество задач, которые решаются и без нейронных сетей, и в современных реалиях их решают с помощью «искусственного интеллекта» только потому что это модно и трендово. Например, задача понимания естественной речи вполне решаема безо всяких нейронок, а тупо по старинке, с помощью регулярок и алгоритмов. Стенфорд достаточно давно выложил в публичный доступ свою библиотеку по обработке естественной речи (http://stanfordnlp.github.io/CoreNLP/) и какой-то парень из университета Ватерлоо написал приложение на питоне (https://github.com/ayoungprogrammer/nlquery), которое отвечает на вопросы естественного языка. Даже с демо: http://nlquery.ayoungprogrammer.com/. Список того, что умеет приложение не аховое, конечно, но видно, что нейронки нужны далеко не всегда.
В качестве морали скажем, что выбирать инструменты по задачам, а не по популярности. И если бы все так делали, то MEAN.io не существовало бы.
Вымышленный диалог про невымышленную проблему современного javascript о том, как все устали от джаваскрипта, и о том, что никто не хочет в этом признаваться. Сейчас сделать любое сколь угодно маленькое веб-приложение просто вопиюще требует иметь гору сборщиков, библиотек, компиляторов и интерпретаторов. Иногда по нескольку штук. Более того, даже серверно-ориентированые фреймворки перекладывают заботу о работе с браузерами и с манипуляцией страницами на сторону джаваскрипта и его инфрастуктуры. Существует даже теория, что "какой бы фреймворк или язык вы бы не начали изучать, через пару часов вы будете дебажить джаваскрипт". В общем очень правдивая и очень печальная юмореска.
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
Очень хороший пример использования нейронных сетей. Yahoo выложил в открытый доступ исходный код свей библиотеки для определения контента для взрослых. Да, это классификатор, который определяет порно в картинках, мультиках, скетчах и фотографиях. Входящему изображению присваивается баллы безопасности изображения от 0 до 1. Картинки с рейтингом меньше 0.2 считаются вполне безопасными, а вот 0.8 и выше практически наверняка будут NSFW. Исходный код доступен на гитхабе, а подробнее можно почитать в блоге Yahoo. Интересно как эту библиотеку можно использовать за пределами Yahoo.
Читать полностью…
Помните тест, в котором нужно было сосчитать количество передач баскетбольного мяча? Если вы не видели, то посмотрите, прежде чем читать дальше.
В 2004 году был сформулирован принцип «ложной слепоты». Этот термин объеденяет в себе несколько разнообразных феноменов нашего восприятия. Обычно выделяют два вида ложной слепоты: слепоту невнимания и слепоту к изменениям. Слепота невнимания (или перцептивная слепота) подразумевает неготовность нашего мозга воспринимать изменения, которые мы не ожидаем увидеть. Как гориллу в ролике, которую уже окрестили «невидимой гориллой» и даже сайт отдельный есть по этому поводу. Еще причиной называют рассеянность, которая вызванная необходимостью полностью сконцентрировать внимание. Очевидно, что на себе вы этот феномен можете почувствовать только если о нем не знаете. И действительно, при повторном эксперименте с другими футболистами и совершенно другой макакой вы ее обязательно заметите, так как ожидаете ее увидеть.
Слепоту к изменениям тоже можно заметить гораздо проще, есть довольно много роликов в интернете на эту тему. Даже BBC снял передачу, посвященную этому феномену. В обычных условиях изменение наблюдаемой картины мгновенно обращает на себя внимание. Однако мы можем не замечать изменения, если они совпадают с коротким прерыванием наблюдаемой картинки. Это может быть кратковременное моргание экрана, монтажный стык видео или короткая помеха. В экспериментах по слепоте к изменениям обнаружилось, что почти 70% испытуемых не замечали подмены главного действующего лица, а изменения менее существенных деталей оставались проигнорированными почти в 100% случаев.
Казалось бы, отвязанный от программирования термин и совершенно не понятно как знание о этой слепоте можно применить. Но можно. Разработчик может быть настолько сосредоточен на решении конкретной задачи, которая полностью захватывает его внимание, что не видит очевидных проблем в соседнем методе или решает задачу каким-то странным образом. Отсюда и возникает требование делать ревью кода, идеи парного программирования и концепция работы по технике помидорок, хотя не все могут четко сформулировать почему эти требования существуют. Еще в команде всегда найдется такой разработчик, который будет неимоверно крут на фоне всех остальных, и его код, как правило, отсматривается сквозь пальцы. И менее опытные разработчики стесняются делать замечания более опытному товарищу. При отсмотре кода своего коллеги внимательно изучайте то, что могло быть пропущено по этому принципу и помните про эффект ложной слепоты.
Довольно часто, перед тем, как оформить свой код в commit, приходится на мгновение задуматься и найти самое подходящее имя коммиту. Или же придумать название небольшому проекту на github.
В основном, эти названия подчиняются правилам (https://github.com/erlang/otp/wiki/writing-good-commit-messages). Иногда несут какой-то позитивный посыл.
Реже - негативный.
Слово f#ck: встречается на github у 1291го пользователя в профиле, 1252572 раза в коде, 36586 раз в issues и в названиях и описании 3153 проектов.
На удивление, ref#cktoring не так популярно. Всего 10 issues и 49 упоминаний в коде.
Sh#t встречается в названиях и описании почти 4 с половиной тысяч проектов. 1706311 раз встречается в коде и украшает информацию о 1145 пользователях. Довольно часто присутствует в wiki проектов - 2668 раз.
Более поэтичное bullsh#t встречается в несколько раз реже. 502 тысячи раз в коде, 6404 раз в названиях проектов и у 51 пользователя в описании.
Слово b#tch - не редкость на просторах github.com. Возможно, оно как-то связано с битами, а ch - сокращение от channel. Так или иначе, его вы можете встретить более 500000 раз.
Чаще всего, в топе языков, при поиске этих слов, появляются JavaScript, Java, Python и Ruby. Скорее всего, это свидетельствет о популярности этих языков.
Подборки различных репозиториев по различным темам гитхаб ведет уже давно на отдельной странице (https://github.com/showcases) и подборки там достаточно качественные, хоть и не сильно часто обновляемые. Значительно бóльшую популярность нашли отдельные репозитории, в которых центром внимания становятся readme.md файлы с кучей ссылок на полезные ресурсы, библиотеки или что-то там еще в контексте тематики репозитория. И, конечно же, есть главный репозиторий, который включает в себя список репозиториев с такими вот подборками, сортированные по темам: https://github.com/sindresorhus/awesome Похоже, именно с этого репозитория нужно начинать изучение новой платформы, языка или технологии. Отдельного упоминания заслуживает секция "Другое" в этом списке. Туда вошло много таких подборок, которые можно изучать часами. Например список различных сервисов, так или иначе с бесплатным доступом для разработчиков: https://github.com/ripienaar/free-for-dev
Что самое интересное в таких подборках, что каждый читатель может предложить как улучшить или дополнить этот список, через обычный пулл реквест. Похоже на сервисы социальных закладок из прошлого десятилетия по типу del.icio.us, только в гите и с публичным обсуждением и на гитхабе.
"Плохой программист Джон сделал ошибку в коде, из-за которой каждый пользователь программы был вынужден потратить в среднем 15 минут времени на поиск обхода возникшей проблемы. Пользователей было 10 миллионов. Всего впустую потрачено 150 миллионов минут = 2.5 миллиона часов. Если человек спит 8 часов в сутки, то на сознательную деятельность у него остается 16 часов. То есть Джон уничтожил 156250 человеко-дней ≈ 427.8 человеко-лет. Средний мужчина живет 64 года, значит Джон убил примерно 6 целых 68 сотых человека. Как тебе спится, Джон — серийный программист?"
Читать полностью…
В мире NodeJS библиотеки двухмесячной давности уже считаются устоявшимися. Еще в этой инфрастуктуре очень тяжело со стандартами. Например, компиляцией ассетов умеет заниматься четыре разных популярных библиотеки: Brunch, Webpack, Grunt, Gulp. Все разные и все популярные. Обязательно нужно разработать пятую, которая будет лучше предыдущих и наконец введет стандарт конфигураций.
Читать полностью…
Когда разрабатываешь новую библиотеку, один из главных вопросов - название. Название должно быть словом, которое знакомо каждому, но, в то же время, будет достаточно оригинальным и, хоть немного, отразит сущность библиотеки.
Ребята из ruby сообщества сталкиваются с этой проблемой довольно часто. На момент написания на rubygems.org в общий доступ выложено 7716 gem'ов.
Мы решили объединить gem'ы Солнечной системы и немного в них разобраться:
Sun ( https://rubygems.org/gems/sun ) - простая библиотека для расчета времени восхода и заката для заданной даты и координат.
Mercury ( https://rubygems.org/gems/mercury ) - фреймворк, написанный поверх Sinatra. Позволяет создавать приложения, используя haml, sass, coffee-script и markdown.
Venus ( https://rubygems.org/gems/venus ) - генератор для добавления и настройки гемов в приложение, написанное с использованием Ruby on Rails.
Earth ( https://rubygems.org/gems/earth ) - набор моделей данных обо всем на свете. Страны, автомобили, zip-коды городов, породы домашних животных и так далее.
Mars ( https://rubygems.org/gems/mars ) - фреймворк, который очень напоминает Mercury.
Jupiter ( https://rubygems.org/gems/jupiter ) - библиотека, предназначенная для ускорения развертывания новых виртуальных машин путем клонирования существующей виртуальной машины, даже если она была запущена, или с помощью предварительно созданных шаблонов.
Saturn ( https://rubygems.org/gems/saturn ) - если верить описанию, то это должен был быть gem для постройки сверхзвуковых летательных аппаратов на Ruby, однако разработка так и не началась 😞
Uranus ( https://rubygems.org/gems/Uranus ) - еще один замечательный gem, который так и не был разработан.
Neptune ( https://rubygems.org/gems/neptune ) - DSL, который позволяет разворачивать приложения на поддерживаемых облачных платформах.
Pluto ( https://rubygems.org/gems/pluto ) - gem, который позволяет создавать веб-страницы, используя открытые источники.