Перевод статьи Валинды Чен.

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

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

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

В этой статье мы пройдёмся по всем этапам использования сайта, как если бы это делал обычный человек, измерив длительность каждого из них. И особое внимание уделим конкретному шагу на одном конкретном сайте, который может быть ещё больше оптимизирован. Хочется верить, что решение (которым будет машинное обучение) может быть использовано во многих различных случаях на разных сайтах.

Перевод статьи Стивена Хубера.

Многие читают и ссылаются на статью 2013 года “How Do Users Really Hold Mobile Devices?”. Но с тех пор было проведено немало исследований и экспериментов по использованию разных методик в реальных продуктах, написано много других статей. За прошедшие годы стало больше известно о том, как люди удерживают свои смартфоны и планшеты, как они взаимодействуют с ними тактильно. И всех этих, зачастую неожиданных данных, нет в старой статье 2013 года. И это её главная проблема. В ней были сделаны предположения, основанные на наблюдениях за использованием десктопов, на стандартах для более старых способов взаимодействия, а также на казусных ситуациях и неверно интерпретированных данных. Но благодаря дальнейшим исследованиям и более качественному анализу удалось отвергнуть ошибочные предположения и докопаться до истины.

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

Перевод статьи Брайна Беренда.

Когда вы впервые приступаете к изучению теории анализа и обработки данных, то одними из первых вы изучаете алгоритмы классификации. Их суть проста: берётся информация о конкретном результате наблюдений (data point), на основании которой этот результат относится к определённой группе или классу.

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



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


Всё верно! Сегодня мы поговорим о Распределяющей шляпе (Sorting Hat) из мира Гарри Поттера. Возьмём какие-то данные из сети, проанализируем и создадим классификатор, который будет сортировать персонажей по разным факультетам. Должно получиться забавно!

В апреле в Минске прошла большая IT-конференция United Dev Conf, организованная Frontend Dev Conf, Highload Dev Conf и Mobicode.

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

В Минске нас встретила хмурая погода и строгие пограничники. Закончив с формальностями, мы направились в самый центр города, к месту проведения конференции. Впереди нас ждали два дня интересных докладов и общения.

Конференция проходила в четыре потока: Frontend, Highload, Mobile и Sales. Её посетили около 700 участников, и 40 докладчиков делились своим опытом. А в перерывах компании-спонсоры разыгрывали квадрокоптеры, куда ж без них на IT-ивенте.

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

В апреле наши коллеги побывали на международной конференции по системному и бизнес-анализу Analyst Days 2017, проходившей в Москве. Под катом — впечатления от самых интересных, на наш взгляд, докладов этой конференции.

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

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

Для этого нужно учесть достаточно большое количество характеристик, от «как быстро всё будет работать» до «а необходима ли нам эта фича?». И так каждый раз. Именно в моменты мозгового штурма команда сравнивает удобство фреймворка, скорость, набор фич, которые реализованы в нем или в совместимых с ним модулях.

Но какой же всё-таки лучше, быстрее и производительнее?

Разработчики постоянно проводят сравнение фреймворков, чтобы прояснить для себя этот вопрос. Например, в статье Lukasz Kujawa приведено сравнение PHP фреймворков. Одно «но» — статья за 2013 год. А ведь время идёт… Поэтому мы решили провести своё, актуальное сравнение фреймворков.

Для оценки производительности был использован PHP Framework Benchmark. Он предлагает для сравнения множество фреймворков (не только указанных выше), но автор не спешит добавлять в репозиторий новые версии проектов, что, конечно же, печально, хотя и не смертельно. При желании добавить новую версию не сложно. 


Одной из основных целей данной статьи также является попытка практическим путем определить улучшения в производительности и эффективности новых версий PHP. Поэтому тестирование было проведено на РНР 5.6/7.0/7.1

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

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

В сентябре 2016 года наши iOS-разработчики побывали в Вашингтоне на конференции CocoaConf DC, где получили массу интересного опыта. Там было очень много увлекательных докладов по разным направлениям, различного уровня сложности. В этой статье мы бы хотели рассказать о докладе, который заинтересовал своей необычностью и новизной — «Creating a Server Side Application with your Favourite Language: Swift!» Джонатана Гатри (Twitter, Github). Джонатан является одним из разработчиков Perfect — фреймворка, который позволяет использовать язык Swift в разработке серверных приложений. Эта тема интересна многим iOS-разработчикам, ведь большинство «домашних» идей останавливает проблема реализации серверной части. При этом изучение дополнительных языков или привлечение сторонних людей не добавляет энтузиазма.

В статье сделан упор на теоретическую часть вопроса, а не на код. Практические руководства можно найти в разделе «Дополнительные материалы», или же в поисковике.

Приглашаем вас в iThink — уже пятое сообщество от NIX Solutions! Впереди первая конференция, и мы приглашаем как начинающих, так и опытных разработчиков присоединиться к нашему iOS-комьюнити. На встрече вы сможете познакомиться и пообщаться с четырьмя экспертами iOS-разработки, прокачаться в трех актуальных темах, узнать много нового и устроить себе насыщенный вечер пятницы.

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

В этом руководстве мы рассмотрим все этапы алгоритма автоматического размещения элементов из модуля CSS Grid Layout. Каждый этап управляется с помощью свойства grid-auto-flow. В своих других статьях “Introducing the CSS Grid Layout” и “Seven Ways You Can Place Elements Using CSS Grid Layout” автор рассмотрел спецификацию CSS Grid и проанализировал, как с помощью Grid можно позиционировать элементы на веб-странице. Однако в этих материалах в сетке явным образом задавалась позиция единственного элемента. Остальные элементы размещались с помощью некоего алгоритма.

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

Отмечаем 5-летний юбилей ThinkPHP вместе на четырнадцатой встрече нашего комьюнити! Пять лет интересных встреч, насыщенных докладов, оживленных кофе-брейков и уютных пятничных вечеров — и ThinkPHP #14 продолжает эту традицию. Вас ждут крутые спикеры, актуальные темы мира PHP, вкусные кофе-брейки и многое другое.

Собираемся на Sync.NET #4, друзья! Традиционно в программе ивента крутые доклады и не менее крутые спикеры, отличный кофе и не менее вкусные сладости, встреча со старыми и новыми знакомыми, приветливый фотограф, дружелюбные бариста и много-много интересного.
Кратко о спикерах и докладах — под катом.

Перевод статьи, посвящённой использованию ReactJS для создания фронтенда.

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

В этой статье мы рассмотрим некоторые проблемы, с которыми можно столкнуться при использовании React во время веб-разработки. Также вы узнаете, почему автор статьи решил разработать новый фреймворк на Scala, благодаря которому удалось сократить количество строк кода с 30 тысяч (на React) до одной тысячи.

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

React Native — это JS-фреймворк для создания нативно отображаемых iOS- и Android-приложений. В его основе лежит разработанная в Facebook JS-библиотека React, предназначенная для создания пользовательских интерфейсов. Но вместо браузеров она ориентирована на мобильные платформы. Иными словами, если вы веб-разработчик, то можете использовать React Native для написания чистых, быстрых мобильных приложений, не покидая комфорта привычного фреймворка и единой кодовой базы JavaScript.

Конечно, мы и раньше слышали обещания об универсальной разработке приложений, с помощью фреймворков наподобие Cordova или Titanium. А что насчёт React Native? В этой статье мы рассмотрим данный фреймворк и особенности его работы и поговорим о том, насколько удобно использовать React Native для написания iOS- и Android-приложений.

Предлагаем вашему вниманию переводной материал об использовании map и reduce в функциональном JavaScript. Эта статья будет интересна в первую очередь начинающим разработчикам.

За всеми этими разговорами о новых стандартах легко забыть о том, что именно ECMAScript 5 подарил нам ряд инструментов, благодаря которым мы сегодня можем использовать функциональное программирование в JavaScript. Например, нативные методы map() и reduce() на базе JS-объекта Array. Если вы до сих пор не пользуетесь map() и reduce(), то сейчас самое время начать. Наиболее современные JS-платформы нативно поддерживают ECMAScript 5. Использование этих методов позволит сделать ваш код гораздо чище, читабельнее и удобнее в обслуживании. map() и reduce() помогут вам встать на путь более элегантной функциональной разработки.

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

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

Хотя JavaScript поддерживает методики функционального программирования, он не оптимизирован для полноценного использования этой парадигмы, как Haskell или Scala. Не обязательно добиваться того, чтобы ваши JS-программы полностью соответствовали концепциям функционального программирования. Но их применение помогает поддерживать чистоту кода и концентрироваться на создании архитектуры, которая легко тестируется и может использоваться в нескольких проектах.

Предлагаем вашему вниманию перевод статьи, посвящённой рассмотрению используемых в программировании моделей памяти.

Сегодня в программировании доминируют шесть основных моделей памяти (не путать с моделями памяти Intel 8086). Три из них проистекают из трех исторически наиболее важных языков программирования 1950-х годов — COBOL, LISP и FORTRAN, а остальные связаны с тремя исторически важными системами хранения данных: магнитная лента, иерархическая файловая система в Unix-стиле и реляционная база данных.

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

Это перевод статьи, которую Марико Косака написала в качестве альтернативного введения в промисы JavaScript. Наброски иллюстраций она делала в своём блокноте во время чтения разных статей, посвящённых промисам. Если хотите изучить более подробно, в конце вы найдёте список полезных ссылок.

Недавно Марико участвовала в обсуждении того, как можно с помощью JavaScript сделать фичу, которая давала бы доступ к внешним данным (должна была быть асинхронной). Она сказала: «Ну, давайте используем fetch()… так что в коде… эээ...», и пока силилась вспомнить fetch API, собеседник сказал: «Будет возвращаться промис». По словам Марико, её мозг впал в ступор, и она сказала: «Честно говоря, не знаю, что ты имеешь в виду…»

Ей приходилось много раз писать код, основанный на промисах, но для полной картины нужные пазлы в её голове почему-то не соединились. Она поняла, что на самом деле не «въезжает» в суть.