Disclaimer

Текст не претендует на истину в последней инстанции, описанное ниже основано на собственном опыте и рекомендациях людей с больше чем двадцати годами опыта в IT в США и Канаде.

Анализ резюме рекрутером

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

У вас есть 3-5 минут чтобы заинтересовать своим резюме. Это то, сколько будет уделено времени на него в начале, в лучшем случае. Часто резюме могут отсеяться спустя 10 секунд. Вас никто не знает, вы это лист бумаги с текстом, и это единственное, что вас может отличить от других. Представьте, что вы хотите купить новый телевизор, вас вряд ли будут интересовать длинные мануалы или 5 страничные описания. Выбирая из десятков и сотен аналогов, нужно за 5-10 секунд сделать предварительный отсев по определенным параметрам. Оставшимся 5-10 устройствам вы выделите чуть больше времени, а потом еще помешкаете выбираю между двух. Как то так и происходит отбор кандидатов.

WebInspector

Мощный инструмент для дебаггинга JavaScript, полноценный инспектор кода для Sublime. Фичи: установка брейкпоинтов прямо в редакторе, показ интерактивной консоли с кликабельными объектами, остановка с показом стек трейса и управление шагами дебаггера. Все это работает на ура! А еще есть Fireplay от Mozilla, который позволяет подключаться к Firefox Developer tools и максимально простой дебаггер JSHint.

_{Кредит — это когда банк вас грабит и вы ему за это ещё платите.
Пожарный Сидоров бездействовал: банк горел — кредит гасился.}


Привет, Хабр!

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

Привет, Хабр!

Вчерашняя моя статья (Наглядно о том, почему я не беру кредиты) вызвала очень сильную реакцию, возможно даже кого-то задела за живое, тогда извиняюсь. Главным образом мне указывали на ошибку, что не учитывается стоимость аренды квартиры, пока Вася копит нужную сумму на вкладе. Что же, дельное замечание, спешу исправить свои ошибки (ведь не ошибается тот, кто ничего не делает, не так ли?).
В конце бонус — онлайн калькулятор с графиками, (преферансом… ну вы поняли).

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

Hello world! Меня зовут Слава, я работаю верстальщиком в агентстве Coalla. Эта статья не о разжигании холивара и рассуждения о том, какой браузер лучше, как бы всем легко жилось без Internet Explorer’a, а мой недавний полезный опыт по установке всех необходимых браузеров и их версий на одну операционную систему, а именно на Microsoft Windows 7 Ultimate x64.

Рассмотрим один из вариантов создания нескольких страниц или вкладок (в том числе вложенных) на html и css без скриптов, списков и таблиц, на одной html странице. Только дивы, только хардкор. Подходит для небольших портфолио и элементов интерфейса. Не будьте буратинами используя это везде подряд.
Суть:

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



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

С недавних пор я стал работать в сфере web разработки, и еще нахожусь в стадии падавана. Однако недавно я открыл для себя способ организации клиентского javascript кода, который может быть легко интегрирован в любой существующий проект и который легко освоить.

Этот подход называют «Модульный javascript», и под катом мы научимся его применять.

В декабре прошлого (2013) года было обнародовано сделанное на специальной пресс-конференции заявление Александра Гостева (эксперта «Лаборатории Касперского»), согласно которому нынешний (2014) год станет последним годом для Интернета в России. Власти России, как сообщил Гостев, нацелены создать национальную сеть с ограниченным доступом к иностранным ресурсам.

Месяцем позже (в январе нынешнего года) появление законопроекта, предусматривающего уведомительный порядок создания серверов в Интернете, показало наинагляднейше, что Гостев скорее преуменьшил масштабы намерений отечественных законодателей. Сперва (26 февраля) стало известно, что этот законопроект одобрен комитетом Госдумы по информационной политике, что он готовится ко прохождению первого чтения в Госдуме; затем, буквально через два дня (28 февраля) стало известно также, что законопроект был принят Госдумою в первом чтении. Каким же окажется дальнейшее развитие событий? Можно подозревать, и небезосновательно, что в итоге всё сложится примерно так же, как получилось с митингами и иными массовыми сборищами граждан: прописанный в законе уведомительный порядок закономерно со временем превратится de facto в разрешительный, а количество таких серверов, разрешённых к массовому посещению через Интернет в России, окажется более близким к той прозорливой и мрачной оценке ≈1943 года, которую иногда приписывают Томасу Дж. Уотсону, тогдашнему президенту IBM (см. фото) — не более пяти штук в год.

Сразу скажу: стремясь с максимальною пользою употребить пару-тройку сотен последних дней существования Хабрахабра, я, уж конечно, не стану обсуждать политические меры противодействия вышеозначенной законодательной инициативе, ведь правилами Хабрахабра это запрещается. Также я ни словом не коснусь её влияния на бизнес, чтобы не попасть за это в хаб-оффтопик. Как раз наоборот — предметом моей заботы станет практическое выживание вполне некоммерческих социальных сообществ, притом достигаемое не политическими, а сугубо айтишными средствами. Вот почему изложенные ниже мысли хочется донести не только до Хабрахабра (что частично получилось бы и с оффтопиком), но также и до внешних (по отношению к Хабрахабру) сообществ его незарегистрированных читателей. За такое нынче, правда, также с недавних пор попадают — да не в хаб-оффтопик, а прямо в чёрный список Федеральной службы охраны (коллекционирующей имена, адреса и другие данные о негативно настроенных интернетчиках) — но это, по-видимому, неизбежное зло. Не всем дано, единожды постигнув пользу Интернета, позитивно относиться к намерениям тех лиц, которые сейчас его деятельно ненавидят и стремятся уничтожить. Скорее дано противоположное. Подозреваю поэтому, что недалёк уж и тот час, когда недовольство сделается поголовным — и ФСО неизбежно придётся закупить базу абонентов Ростелекома (и других провайдеров) да воспользоваться именно ею вместо собственных чёрных списков.

Суть такова: к грядущему постепенному уничтожению Интернета неплохо бы оказаться готовым. Готовы ли вы? Возможна ли альтернатива Интернету, свободная от фатальных недостатков, предопределивших его уничтожение?

Предлагаю простое мысленное упражнение ума. Вообразите себя участником обширного социального сообщества, сформировавшегося в Интернете и объединяющего жителей различных отдалённых городов — объединяющего граждан, вполне далёких от личного знакомства и общения в так называемом реальном мире. Один или два сервера, важных для этого сообщества, ужé показывают «ошибку 451°» вместо своей заглавной страницы; а совсем скоро (возможно, ужé къ столѣтію Міровой войны?…) всѣ, всѣ его серверы въ Интернетѣ раздѣлятъ ту же судьбу въ Россіи: сѣть «Интернетъ» станетъ для нихъ «Интернѣтомъ» (отъ слова «нѣтъ»).

Кроме того, вы айтишник.

Довольно часто на сайтах е-коммерса нас просят реализовать фильтры. Хороший фильтр — довольно дорогая игрушка. Вообще, они не всегда уместны — пользователю проще посмотреть глазами на список, чем разбираться в логике разработчика фильтра. Конечно, если в этом списке не так много элементов. Скажем, не больше 200 в каждом разделе. Ниже в виде проверочного списка для наших QA, я зафиксировал некоторые требования, которые мы настойчиво внедряем на своих проектах с этого года. Стандартизация, ептэ.

Эти требования разумны. Часть из них трудно реализуема. Часть — очевидна. Часть — зависит от контекста. Но в целом они довольно универсальны. Если будут какие-то вопросы по конкретным пунктам — велкам в комментарии.

Мишко Хевери, главный разработчик Ангуляра, как-то упомянул, что приложение гарантированно работает без тормозов, если в нем не более 100 активных областей видимости. Такой подход, в общем, применим к любым приложениям. В играх давно не рендерят то, чего игрок не видит и только в вебе пока еще считается нормой отобразить целиком список из нескольких тысяч элементов. С приходом js-фреймворков ситуация должна измениться и лучшим решением станет удаление из DOM того чего нет на экране, нежели отказ от промежуточных тегов, биндингов и других вещей, облегчающих разработку. Поэтому провел небольшой анализ решений для отображения больших списков. Наткнулся на пару статей:

1. The Infinite Path of Scrolling

В ней парень рассказывает, что проходил стажировку в Гугле в команде Ангуляра и ему поручили исследовать этот вопрос. (Радует, что разработчики заинтересованы этим. Надеюсь, скоро увидим родную поддержку бесконечного скролла).

Angular — зрелый и мощный JavaScript-фреймворк. Он довольно большой и основан на множестве новых концепций, которые необходимо освоить, чтобы работать с ним эффективно. Большинство разработчиков, знакомясь с Angular, сталкиваются с одними и теми же трудностями. Что конкретно делает функция digest? Какие существуют способы создания директив? Чем отличается сервис от провайдера?

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

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

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

Загрузка приложения и менеджер состояний

До момента загрузки самого фрэймворка, его зависимостей и отработки всех запросов в бэкграунде приложение может выглядеть весьма удручающе. И даже ng-cloak не сможет помочь в большинстве случаев. Обычно для таких целей используют div имеющий больший z-index чем основной контент сайта и перекрывающий его до загрузки всех компонентов и состояний. Он может выглядеть так:

<div class="loader" ng-show="loader"><div class="loader-content">Loading...</div></div>

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

Давайте я расскажу вам, какой это замечательный процесс.

Вряд ли я открою Америку, если скажу, что для широких слоев населения изделия компании GoPro если не тождественны, то синонимичны понятию «экшн-камера». Понятно, что при таком «раскладе» у популярной продукции неизменно должны возникать «убийцы», которые позиционируются в качестве прямого конкурента. В данном случае я не беру в счет кЕтайские экшн-камеры, которые способны таить множество неприятных сюрпризов от интерполяции видео до нестабильной работы или посредственного качества сборки. Об авторитетности безымянных производителей речь и вовсе не идет.

Итак, ко мне попала модель американской iON Air Pro Wi-Fi, которая явно метит в соперники как минимум GoPro HERO3: White Edition. Заметно это хотя бы по цене – модели стоят примерно одинаково. То есть, у iON в России есть только один официальный дистрибутор, и с разбежкой цен проблем нет – если покупать, то только за 9 990 рублей (~$312). У GoPro в силу обилия «серого импорта» и множества поставщиков все гораздо сложнее. На Яндекс.Маркет ценник в среднем выше 9 000 рублей, а в крупных розничных сетях типа «Связной» или «Юлмарт» достигает аккурат уровня модели iON.

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

Проблемы git-flow

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

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

Разработка

Я расскажу о цикле разработки через Github, который я использую. Он был проверен в течении года на командах разного размера: 3 — 14 человек.

Существует 2 основных ветки: master и dev.

master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент.

dev — ветка, над которой в данный момент работает команда.

Итак, в начале разработки master и dev ветки идентичны.

Давно писал модуль для загрузки файлов и всё он был не идеальным. И тут подумал, если сейчас не опубликую, то никогда не опубликую, идеал-то не достижим!

При составлении АПИ руководствовался принципом — как можно проще. Поэтому сначала несколько мыслей о загрузке файлов:

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

Загрузка каждого файла отдельным запросом. На любом хостинге существует ограничение на максимальный размер POST-запроса (напр., 10 МБ). Если мы грузим одновременно 10 файлов, значит их вес в сумме не должен превышать 10МБ. В 99% случаев проще пожертвовать производительностью и не иметь проблем с такими ограничениями.

Никаких отложенных загрузок. Файл должен загружаться сразу после добавления (не в 2000 году, чай, живем), поэтому никаких методов работы с очередью — выбрал файл, выбрал еще 5 штук, удалил один, нажал «отправить» — не будет. Зато будет отмена загрузки.

Не стоит разделять загрузку файлов по кнопке и перетаскиванием. В моем случае любая область, помеченная директивой позволяет перетаскивать на нее файлы, а если это инпут с типом file, то еще и в проводнике можно выбрать. Очень удобно знать, что на кнопку можно перетаскивать, когда потянул в браузер 10 файлов, а дизайнер забыл подсветить поле перетаскивания, и гадаешь перетащатся ли они или откроются в новом окне.

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

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

Большинство web-приложений и web-фреймворков используют архитектуру, не позволяющую разделить ui и backend разработку. Тем самым нет возможности разделить команду на узкоспециализированных frontend и backend разработчиков. Вне зависимости от предпочтений разработчика ему приходится иметь понимание как о слое представления, так и о слое логики. Если ui-разработчик знает только о том, как запустить сервер, и о модели данных — это огромная удача. В плохих случаях ui-разработчику необходимо провести полную сборку проекта чтобы увидеть изменения строчки в javascript файле, или знать о языке jsp файлов чтобы поменять стиль элемента. Формирование и передача на сервер обработанных html файлов так-же пагубно влияет на производительность сервера и сети.