Долгое время работая в разных сферах ИТ, мы с исследовательской командой наблюдали все возможные проблемы становления разработчиков и все причины-следствия их дефицита. Нас интересовало: почему программист развивается в senior-специалиста так долго или вовсе им не становится? Откуда неоправданные ожидания с обеих сторон? И главное — что делать разработчику на каждом уровне, чтобы войти в привилегированную касту senior-ов, архитекторов, тимлидов и руководителей?

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

Senior, who the f… is Alice Senior?

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

Преамбула

Для того, чтоб описать и задокументировать правила клиент-серверного
взаимодействия используя Rest-api можно выделить три основных метода:

1. Описывать своим коллегам правила обращения к серверу на пальцах
   Этот метод быстр и не требует долгосрочной поддержки, но высока вероятность, что вас за это будут бить.
   
2. Руками составлять Google-docs/Wiki/Readme в проекте
   Удобно тем, что однажды написанная документация не требует повторного объяснения. Её можно показать коллегам и даже иногда заказчику. Минусом данного метода является долгосрочная поддержка такой документации. Когда Api в проекте вырастает до таких размеров, что сама мысль "А когда же я обновлял документацию?" вызывает холодок по спине, тогда вы понимаете, что дальше так продолжаться не может. Формально вы можете обновлять документацию очень часто и маленькими фиксами, но это до первого отпуска.

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

В большинстве приложений, которые разрабатываются в наши дни, требуется взаимодействовать с некими наборами данных. Обработка элементов в коллекциях — это часто встречающаяся операция, с который вы, наверняка, сталкивались. При работе, например, с массивами, можно, не задумываясь, пользоваться обычным циклом for, который выглядит примерно так: for (var i=0; i < value.length; i++ ){}. Однако, лучше, всё-таки, смотреть на вещи шире.



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

На самом деле, такие средства в JavaScript имеются. Некоторые из них рассмотрены в материале, перевод которого мы представляем сегодня вашему вниманию. В частности, речь идёт об операторе расширения, о цикле for…of, и о методах includes(), some(), every(), filter(), map() и reduce(). Здесь мы, в основном, будем говорить о массивах, но рассматриваемые здесь методики обычно подходят и для работы с объектами других типов.

Так получилось, что за свою карьеру front-end разработчика, я побывала на многих собеседованиях. Тема прохождения интервью не теряет своей актуальности, а в комментариях, когда речь заходит о собеседованиях, начинают ломаться копья. Хочу тоже внести свой вклад и поделиться накопившейся коллекцией вопросов. Прошу.

Со временем языки программирования постоянно изменяются и развиваются из-за появления новых технологий, современных требований или простого желания освежить стиль написания кода. Реактивное программирование можно реализовать с помощью различных фреймворков, таких как Reactive Cocoa. Он изменяет рамки императивного стиля языка Objective-C и у такого подхода к программированию есть что предложить стандартной парадигме. Это, безусловно, и привлекает внимание iOS разработчиков.

ReactiveCocoa привносит декларативный стиль в Objective-C. Что мы подразумеваем под этим? Традиционный императивный стиль, который используют такие языки как: C, С++, Objective-C, и Java и т. д. можно описать так: Вы пишете директивы для компьютерной программы, которые должны быть выполнены определенным способом. Другими словами, вы говорите «как сделать» что-то. В то время как декларативное программирование позволяет описать поток управления как последовательность действий, «что сделать», не определяя, «как делать».

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

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



Веб-воркеры позволяют выполнять JavaScript-код в отдельном потоке, который совершенно независим от главного потока и от того, что в нём обычно происходит.

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

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

Меня зовут Максим, и я алкоголик занимаюсь iOS разработкой уже более 7 лет.

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

Среди кандидатов попадаются кадры, которые курят кальян прямо на Skype собеседовании, пытаются гуглить вопросы на ходу, хотят ЗП 180к за 3 месяца опыта, ведут себя так, как будто гоп-стопнули меня на улице (с соответствующей терминологией) и так далее.

Но в большинстве случаев, даже у адекватных middle специалистов, есть общий пробел: непонимание принципов асинхронного выполнения задач и работы аппаратного ускорения в iOS.

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

(Если лень читать, то прилагается видео)

Камран Ахмед, автор материала, перевод которого мы сегодня публикуем, говорит, что занимается фуллстек-разработкой уже 5 лет и в настоящее время работает на должности ведущего инженера в компании tajawal. Там ему приходится заниматься многими вещами. Ему, по долгу службы, надо быть в курсе того, что происходит в мире веб-разработки, кроме того, одна из его задач заключается в том, чтобы поддерживать знания и навыки других разработчиков в хорошем состоянии. По его словам, наблюдение за развитием технологий — это не только его работа, но и хобби. Ему приходилось видеть сложности, с которыми сталкиваются начинающие программисты (и опытные — тоже), когда речь заходит об оперативном освоении новшеств. Камрану, в прошлом году, часто приходилось отвечать на вопросы о том, в чём нужно ориентироваться для того, чтобы оставаться современным и востребованным программистом. В результате он, для того, чтобы помочь себе и другим, решил подготовить схемы, ссылки на которые отвечали бы на большинство вопросов, которые ему обычно задают.

 
Использование полезных нагрузок (пейлоадов) позволяет проводить фаззинг веб-приложения, для выявления аномалий/признаков уязвимостей. В этой статье я рассмотрю несколько вариантов пейлоадов для тестирования веб-приложений.

В этой статье мы с нуля разработаем React-приложение, обсудим домен и его сервисы, хранение, сервисы приложения и представление (view).

После прочтения ряда статей (например, этой) решил перейти на современный подход с использованием Node.js при написании простых сайтов с подхода «динозавров». Ниже представлен разбор примера сборки простого статического сайта с помощью Webpack 4. Статья написана, так как инструкции с решением моей задачи не нашел: пришлось собирать всё по кусочкам.

Всем привет! Мы не успели оглянуться, как закончились все оффлайн-места на Moscow JS 40, который прошёл в нашем офисе 1 марта. Записаться успели не все желающие. Хорошие новости: уже появились видео и презентации от докладчиков. Под катом — видеозаписи, презентации, ссылки на фотоотчёт и отзывы слушателей.

Участники встречи говорили про мотивацию и трудности создания сервиса скриншотов веб-страниц, обсуждали developer experience и flow, разбирались с AST-парсерами и проводили экскурс в компьютерную лингвистику.

Помните, Льюис Кэрролл писал: «Здесь приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место, нужно бежать вдвое быстрее»? Это фраза прекрасно подходит для IT-мира: технологии быстро развиваются, и каждый день нужно осваивать что-то новое, чтобы оставаться востребованным специалистом. У каждого программиста наверняка есть 5-6 бумажных книг, ставших классикой. О некоторых таких книгах мы уже писали. Но чтобы оставаться востребованным кодером, надо постоянно обновлять библиотеку. В прошлом году портал DevMountain сделал подборку из семи не слишком популярных книг для начинающих программистов. Учитывалась не только оценка портала, но и отзывы на Amazon, а также рекомендации популярных блогов. Автор GeekBrains Илья Бубнов внимательно изучил этот список, а также дополнил подборку парой свежайших экземпляров.

В нашей прошлой статье — «11 «рецептов приготовления» MySQL в Битрикс24» — мы, в основном, рассматривали архитектурные решения: стоит ли использовать облачные сервисы (типа Amazon RDS), какой форк MySQL выбрать и т.п.

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

Еще раз напомню, что эта статья (как и предыдущая) не является универсальным «рецептом» идеальной настройки MySQL на все случаи жизни. :) Такого не бывает. :) Но искренне верю, что она будет полезной для вас для решения отдельных конкретных задач.

А в конце статьи — сюрприз для самых терпеливых читателей. :)

Здравствуйте!

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

Пример использования:

num2str(878867.15); // восемьсот семьдесят восемь тысяч восемьсот шестьдесят семь рублей 15 копеек

Далее сам код…

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

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

UPD (13 марта 2015): Заменил несколько плагинов на более актуальные + решил проблему с импортом CSS файлов внутрь SCSS

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

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

Важные замечания:

• Пункты с неуказанным источником написаны мной самостоятельно. Поправьте меня, если вы заметите какие-то неточности. Предложите лучшую аналогию, если это возможно.
• Заголовки ссылаются на соответствующие им статьи в Wikipedia. Пожалуйста, читайте эти статьи для более серьезных и детальных объяснений.
• Аналогии — отличный способ объяснить материал, но они не идеальны. Если вы хотите по-настоящему понять перечисленные концепции, вам следует начать с фундаментальных азов и рассуждать, исходя из них.

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

1 Введение

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

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

В прошлом году мы рассказывали про разработку приложения Контур.Эльба под Android (причем неоднократно). Реализовав в нем все задуманное, мы принялись за разработку версии под iOS, которая недавно появилась в App Store. Пост про разработку с использованием Xamarin.Forms будет позже, а пока сосредоточимся на, казалось бы, банальном вопросе: выкладывание приложения в App Store и общение с модераторами.

Начнём с выводов, которые мы получили в процессе общения с модераторами Apple:

• следует внимательно перечитывать App Store Review Guidelines: рекомендации меняются, и то что вчера было разрешено, сегодня могут уже запретить;
• модераторы Apple не всегда внимательно изучают приложение и могут пропустить контент внутри;
• нужно внимательно читать ответы модераторов;
• решение после проверки может не соответствовать правилам App Store. Пример в тексте ниже: требование подключения in app purchase для приложения без поддержки платных фич;
• в непонятных ситуациях лучше сразу написать апелляцию, чтобы не тратить неделю на ожидание ответа. Если ответ не устраивает или непонятен – новые апелляции;
• модерация может занять много времени: минимум 8 дней, из которых 7 дней – ожидание в очереди на проверку.

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

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