Программирование *

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

Данная статья — инструкция по прикручиванию базовой непрерывной интеграции (build-test-deploy) к гитхабовским C/C++ проектам с CMake сборкой — по непонятным причинам, на Хабре такого до сих пор не проскальзывало. Впрочем, если моё гугл-фу подвело меня, и таки проскальзывало — не беда. Лишний туториал, описывающий всё под несколько другим углом и предостерегающий от неповторимого набора набитых автором шишек, совершенно точно не повредит.

Рано или поздно любой разработчик сталкивается с непонятными проблемами, а учитывая множество «особенностей» Vanilla JS, у нас это происходит довольно часто. Вне зависимости от причин поиск решений может затянуться или привести к созданию очередного велосипеда. А верный путь часто лежит на поверхности, нужно просто знать, где его искать и как применить полученные знания. О странностях и неожиданностях JS и их правильной интерпретации мы поговорим с экспертами в этой области Claudia Hernández и Jakob Mattsson.

Сегодня, в 18 часов по московскому времени, в американском Rapid City начнется финал самого престижного мирового соревнования для программистов – ACM ICPC. Приглашаем всех желающих увидеть это событие в прямом эфире (прямая трансляция начнется уже в 17 часов по Москве) и поддержать команду Университета ИТМО – одного из фаворитов чемпионата. О том, как команды со всего мира готовились к финалу, а также о прогнозах на победу расскажем ниже.

Ныне проживающий и работающий в США программист Владимир Игловиков занял второе место в британском соревновании Data Science Challenge. Игловикову должны были выплатить денежное вознаграждение в размере 12 тыс. фунтов стерлингов. Через два дня после окончания конкурса с программистом связались организаторы и объяснили, что не могут выплатить призовые деньги из-за несоответствия критериям конкурса: у Игловикова российское гражданство. Вчера стало известно, что компания Mail.ru выплатит вознаграждение вместо организаторов конкурса.

Владимир Игловиков (профиль на «Хабрахабре» и на «Гиктаймсе» — ternaus) окончил физический факультет Санкт-Петербургского государственного университета со степенью магистра, затем получил Ph.D. в Калифорнийском университете в Дейвисе. Игловиков оставил научную деятельность и ушёл в компанию Bidgely, затем перешёл в TrueAccord на должность старшего научного сотрудника. На данный момент Владимир проживает в США.

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

В пятницу, 19 мая, в нашем московском офисе прошел CocoaHeads-митап для iOS-разработчиков. Разнообразный по наполнению: два выступления докладчиков, викторина на проверку знаний и панельная дискуссия с экспертами из известных на рынке IT-компаний. Видеоотчет – под катом!

Одной из лучших особенностей React является то, что он не накладывает каких-либо ограничений на файловую структуру проекта. Поэтому на StackOverflow и аналогичных ресурсах так много вопросов о том, как структурировать React-приложения. Это очень спорная тема. Не существует единственного правильного пути. Предлагаем разобраться в этом вопросе с помощью статьи Джека Франклина, в которой он рассказывает о подходе к структурированию больших React-приложений. Здесь вы узнаете, какие решения можно принимать при создании React-приложений: о выборе инструментов, структурировании файлов и разбивки компонентов на более мелкие части.

Приглашаем всех желающих на встречу ThinkJava #5! Мы будем обсуждать актуальные темы из мира Java, рассматривать с разных точек зрения тенденции индустрии, делиться опытом, задавать вопросы и получать на них ответы — и всё это в традиционно уютной атмосфере встреч ThinkJava.

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

Как обычно выглядят тесты?

Очень схематично, каждый юнит-тест обычно состоит из следующих шагов:

1. Инициализации входных данных;
2. Выполнения бизнес-логики и получения результата;
3. Сравнения результата с эталоном.

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

Но ведь все это можно унифицировать!

15 мая, спустя многие годы, вышло новое воплощение операционной системы IBM OS/2 от Arca Noae под названием ArcaOS 5.0. Сейчас ОС доступна в двух версиях: для личного и коммерческого использования. Последняя включает в себя приоритетную поддержку и более долгий срок обслуживания.

Мы как программисты иногда попадаем в "программистский ад", место где наши обычные абстракции не справляются с решением ряда повторяющихся проблем.

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

Ад проверки на null

Данная проблема возникает когда несколько частичных функций (функции которые могут не вернуть значение) нужно выполнить последовательно.

Такие функции обычно приводят в глубоко вложенному и сложно читаемому коду с чрезмерным количеством синтаксического шума.

var a = getData();
if (a != null) {
  var b = getMoreData(a);
  if (b != null) {
     var c = getMoreData(b);
     if (c != null) {
        var d = getEvenMoreData(a, c)
        if (d != null) {
          print(d);
        }
     }
  }
}

На этой неделе мы публикуем подборку из задач и вопросов, которые даёт на собеседованиях Uber. Задачи подобрали различного уровня сложности от «Easy» до «Hard», чтобы всем было интересно. Условие дано на английском языке.

Ответы, как и прошлый раз, опубликуем в течение недели. Круто, если вы будете писать в комментариях свои варианты решений )

Вопросы:

1. Какие KPI вы бы использовали, если бы запустили новый сервис Uber в определенной части мира и хотели знать, насколько он успешен?

2. Какой проект, над которым вы работали, провалился? Могли бы вы сделать что-нибудь, чтобы предотвратить его провал?

Всем привет! Это уже девятый выпуск дайджеста на Хабрахабр о новостях из мира Python.

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

А теперь к делу!

Уже в этот вторник, 23 мая, после долгого перерыва, в офисе DINO Systems состоится встреча CodeFreeze с Андреем Ершовым, специалистом по распределенным системам. Тема встречи — CRDT. Бесконфликтная синхронизация данных.

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

Не так давно, на этой неделе, я наткнулся на пост трехлетней давности. Вот он. Если вы будете его внимательно читать, то наткнетесь на то, что возмутит вас до глубины души. Если, конечно, вы понимаете что такое теория вероятностей. Речь об этом отрывке:

«55.55% — вероятность того, что ящики зажгутся одним и тем же цветом, когда мы выбираем две двери наугад, в соответствии с теорией скрытых параметров».

Все мое знакомство с теорвером буквально заорало об ошибке. Но есть нюанс… Я тоже могу ошибаться. Так давайте проверим!

Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков php, ruby и go. Сборщики логов и системы доставки не будут рассматриваться сознательно (их обсуждали уже много раз).

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

(Полный исходный код лежит тут)

Сидя на пятичасовом занятии по химии, я часто скользил взглядом по таблице Менделеева, висящей на стене. Чтобы скоротать время, я начал искать слова, которые мог бы написать, используя лишь обозначения элементов из таблицы. Например: ScAlEs, FeArS, ErAsURe, WAsTe, PoInTlEsSnEsS, MoISTeN, SAlMoN, PuFFInEsS.

Затем я подумал, какое самое длинное слово можно составить (мне удалось подобрать TiNTiNNaBULaTiONS), поэтому я решил написать программу на Python, которая искала бы слова, состоящие из обозначений химических элементов. Она должна была получать слово и возвращать все его возможные варианты преобразования в наборы химических элементов:

• Вход: Amputations
• Выход: AmPuTaTiONS, AmPUTaTiONS

На данный момент существует более 500 различных языков программирования. Следовательно, вполне нормально взять и начать учить новый язык прямо сейчас. Например, вы знаете C++ и Java, но на работе требуется Python, или наоборот. А может быть, вы просто хотите выучить какой-нибудь модный язык, чтобы повысить свою конкурентоспособность?..