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

В течение времени инструменты управления проектами перешли от карандаша и листа бумаги (иногда они и возвращаются в виде Канбан доски в офисе) к софту для управления проектами и спредшитам (как оффлайн, так и онлайн, от простого плана проекта с использованием диаграммы Ганта и Канбан досок, заканчивая комплексными системами), призванными облегчить управление, которые так просто выбрать… и пролететь, потому что непонятно, для чего и в чем премущества.



Поэтому, так или иначе, выбор инструментов не стоит начинать с софта (кстати, здесь был большой список из 43 систем для управления проектами). Беру на себя смелось перевести неплохой гайд по четырем инструментам управления проектами от TakingITGlobal, являющихся базой для многих систем.

Изучение открытого исходного кода – это лучший способ научиться писать качественный код, особенно если речь идет о новом инструменте с не полностью сформировавшимися стандартами. Одним из таких инструментов является React Native. Он постоянно дорабатывается, функциональность его API расширяется с каждым релизом, а количество библиотек растет. В то же время большинство обучающих ресурсов по работе с React Native очень поверхностны и не идут дальше вступительных рекомендаций. Но даже несмотря на это, изучение исходного кода должно быть нормой для каждого разработчика.

Я хочу представить 5 проектов с открытым исходным кодом, которые я изучаю сам и советую остальным.

Устройство для снимка экрана на первых компьютерах (Command-Shift-3)

Если вы когда-либо делали хелп или мануал для своего приложения, наверняка вы отметили, как неожиданно много времени и сил занимает создание скриншотов.

Ведь кажется, что скриншот — это “секунда работы, Alt+PrintScreen и Ctrl+V!”. Некоторые клиенты удивляются, когда слышат, что скриншот в мануале может стоить и $2 и даже $5.

В этой статье я расскажу, как правильно делать скриншоты, почему это не просто “два клика” и какие подводные камни встречаются на пути неопытного скриншотера. Рассматривайте ее как чеклист или список практических советов для тех, кто документирует ПО. Надеюсь, это поможет вам избежать разочарований и порадовать юзеров красочными понятными картинками.

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

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

Лампа накаливания проста, а светодиодная лампа содержит сложную электронную схему, поэтому с диммированием там всё непросто. Сегодня я расскажу, что делают диммеры, чем они отличаются между собой, и как себя ведут диммируемые светодиодные лампы по сравнению с лампами накаливания при регулировке яркости.

Предлагаю вашему вниманию перевод статьи How To Pick a Frontend Web Framework c сайта top.fse.guru.

Привет, приятель!

Ниже ты найдешь большой список компоновки инструментов и фреймворков. Не волнуйся! Ты можешь выбрать один, в котором точно уверен, или проигнорировать все и придумать свой вариант.

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

Вступление

С каждым годом становится всё очевиднее, что для распространения тестовых версий iOS-приложений нужны специализированные сервисы. Это актуально не только для компаний, занимающихся разработкой приложений в “промышленных масштабах”, но и для инди-разработчиков. Причины: увеличение количества устройств с “нестандартным”/”не кратным” размером экрана, отличия в архитектуре центрального и графических процессоров — всё то, что раньше было повседневностью для разработки под Android, теперь становится справедливым и для iOS.

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

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

В обзоре участвуют следующие сервисы (в таком порядке и будут публиковаться части обзора):

• Apple TestFlight
• HockeyApp
• Ubertesters
• Crashlytics (как часть Fabric)

TestFlight старой версии не будет рассмотрен, так как хотя он по-прежнему работает и доступен по адресу www.testflightapp.com, использование его в долгосрочной перспективе не имеет смысла по ряду причин:

• нет никаких гарантий, что Apple не приостановит или не прекратит его работу в любой момент
• SDK сервиса не доступно для скачивания, более того невозможно использовать сервис, если приложение использует SDK
• сервис больше не является кросс-платформенным, поддерживается только распространения приложений для iOS (подробнее)

Важно! Буквально накануне публикации статьи команда TestFlight (старой версии) разослала уведомление, в котором сообщается, что старый сервис прекратит свою работу 26 февраля 2015 года (подробности).

Система оценки: сервисы будут оценены по 10-балльной шкале по каждому из разделов (Регистрация и интеграция, Основной функционал, Дополнительный функционал, Continuous Integration). Суммарная оценка позволит определить победителя (итоговое заключение войдет в последнюю часть обзора).

Axure — инструмент для создания интерактивных прототипов сайтов и мобильных приложений. Навыков работы с ним часто требуют работодатели, ищущие проектировщика интерфейсов или UX&UI-дизайнера. В России это почти что отраслевой стандарт. Axure 7 — последняя версия программы. Восьмая версия сейчас в бете.

В одной школе интернет-технологий (не упоминаю, чтобы не сочли за рекламу) с мая 2015 года я рассказываю начинающим дизайнерам об Axure 7. В течение 3 часов (минус небольшой перерыв) объясняю, как работают те возможности программы, которые нужны мне для большинства проектов. И закрепляю знания практикой.

Примерная структура занятия:

• Примеры прототипов;
• Виджеты, их настройка и расстановка по холсту с помощью сетки, направляющих и выравнивания;
• Мастера;
• Динамические панели;
• Создание интерактива (ивенты, экшены, кейсы, условия);
• Под конец: способы передачи прототипа заказчику, свойства страниц, стили.

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

Встал вопрос централизованного хранения и обработки журналов с серверов на базе Linux и Windows. Мой выбор пал на продукты от Elastic.
Большинство прочитанных статей на тему установки приложений Elastic показались мне достаточно расплывчатыми и неполными.

Несколько дней назад David Demaree, главный по Typekit в Adobe, издал крутую книжку "git для людей". Чтобы привлечь к ней внимание, он опубликовал выжимку самой, на мой взгляд, интересной главы — как оформлять коммиты чтобы и волки были целы, и овцы сыты, и песец не пришел. А я за эти выходные подготовил выжимку из выжимки — сокращенный и адаптированный перевод, чтобы можно было быстро прочитать и добавить в копилку своего опыта самое ценное.

VS Code (Visual Studio Code) — относительно новый текстовый редактор, выпущенный Microsoft. Он, также как и Atom, основывается на облочке Electron (написанной командой Atom), кардинально отличаясь реализацией самого редактора.

VS Code обладает своими уникальными фичами, такими, как, например, IntelliSense "из-коробки".

В этой статье я бы хотел поделиться тем, что нашел для себя полезным в VS Code для веб-разработки.

Осторожно! Под катом много картинок и гифок.

На Хабре уже много писали о методологии БЭМ, выросшей в Яндексе. И мы решили, что пора системно рассказать о том, откуда она появилась и что сделало БЭМ таким, каким мы его знаем. Думаем, это будет интересно не только тем, кто уже использует БЭМ, но и тем, кто считает, что эта методология не подходит для их проектов. Возможно, они увидят, что мы решали проблемы, похожие на их собственные, и найдут что-то полезное для себя.



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

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

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

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

Мы продолжаем публиковать подборки полезных инструментов. Ниже представлена подборка из более 800 сервисов, книг, статей, видеотуториалов и других материалов, которые будут полезны всем, кто занимается фронтенд-разработкой.

Автор анонса — хабрапользователь elnee

---

Доброго вам new Date().toLocaleString(), хабрапользователи. Хочу представить всеобщему вниманию перевод англоязычного словаря терминов для фронтенд-разработчиков.
Если заинтересовались — добро пожаловать под кат.

Доброго времени суток, уважаемые хабравчане! Обычно мои подборки ориентированы сугубо на веб-разработку, но этот выпуск охватывает все сферы программирования. Но самое главное, что интересность и полезность каждого материала имеет социальное доказательство, благодаря замечательному сервису Slant.co. Это некий аналог Quora, сфокусированный сугубо на разработчиков.

Коллекция из почти 200 ответов в Slant на вопросы «Какие лучшие...»

И вновь в эфире цикл переводов полезных советов для веб-разработчика. На этот раз автор расширил спектр исследуемых инструментов, добавив туда редактор Sublime Text и фреймворк Node.js. Предыдущие части: 1-16, 17-32.

Поехали!

Содержание:
   33.  Разворачивание упрощенной записи CSS-свойств
   34.  Определение совпадения селекторов по цвету
   35.  Использование визуальной навигации и просмотр снятых скриншотов процесса загрузки страницы
   36.  Sublime Text: нечеткий поиск при помощи функциональности GOTO
   37.  Быстрое изменение значения CSS-свойств при помощи клавиатуры и колеса мыши
   38.  Прокрутка элемента в области видимости
   39.  Node.js: Использование Babel для запуска ES6
   40.  Переход к просмотру и редактированию CSS или Javascript-файлов из панели «Elements»
   41.  Отображение значений Javascript-переменных рядом с кодом в процессе отладки
   42.  Использование цветовой группировки в панели «Network» для упрощения идентификации типа ресурса
   43.  Активация псевдо классов DOM-элемента
   44.  Инспектирование самих инструментов разработчика
   45.  Запуск выбранного блока кода из панели «Sources»
   46.  Установка условных точек останова
   47.  Переход к следующему вхождению выбранной строки при помощи горячих клавиш
   48.  Редактирование CSS-файла в панели «Sources» и упрощенное изменение значений CSS-свойств

Как-то обошло Хабр стороной появление видеокурса по Redux, созданного Даниилом Абрамовым, автором библиотеки. В первых роликах рассказывается о принципах Redux, а затем поэтапно разбирается разработка веб-приложения на нем.

Вот он: egghead.io/series/getting-started-with-redux

Под катом — перевод введения с сайта курса, egghead.io.

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

• Изначально, React был нацелен на экспертов и ранних последователей
• Facebook открывает исходный код только тех продуктов, которые использует сам, т. е. не нацеленные на проекты-меньше-чем-Facebook
• Огромное количество гайдов по React совершенно разной сложности

Здесь и далее, я предполагаю, что вы уже знакомы с HTML, CSS и JavaScript.

Сейчас в каталогах приложений Apple App Store и Google Play в совокупности размещено около 3 миллионов мобильных программ. Количество приложений стабильно растет, чего нельзя сказать о качестве подавляющего количества уже размещенных программ. Одна из причин такой ситуации — разработчики недостаточно хорошо тестируют приложения, во многом это происходит из-за отсутствия должного опыта.

Профессиональный тестировщик, конечно же, смог бы помочь довести мобильное приложение практически до идеального состояния. Но у большинства разработчиков обычно нет средств на оплату услуг такого профессионала. А пользователи не хотят мириться с плохим качеством. И если пользователь обнаруживает серьезную проблему (чрезмерное потребление энергии, краш приложения, зависание телефона), то 44% пользователей, по статистике, сразу удаляют приложение, не разбираясь с проблемой. 96% таких пользователей пишут плохой отзыв о программе. На самом деле, причин, по которым приложение удаляется, довольно много, мы уже писали об этом в своем блоге. Сейчас давайте поговорим о том, что можно предпринять, чтобы приложение работало, как нужно, радуя пользователя стабильностью, а разработчика — доходом от рекламы.