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

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

Пройдемся по дизайну, серверным решениям, тестированию и аналитике.

Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

Мы всё обсудили? Нет? Что ещё?

В данной статье будет показано как можно реорганизовывать код написанный в «простом» JQuery стиле в код на Backbone, с использованием представлений, моделей, коллекций и событий. Реорганизация будет постепенной, так чтобы этот процесс дал четкое понимание основных абстракций в Backbone. Статья рассчитана на тех кто использует JQuery и хотел бы познакомится со схемой MVC для клиентского кода.

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

7. Производительность скалярных UDF оставляет желать лучшего

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

Посмотрите этот пост о принудительном использовании параллелизма – в частности, список того, что приводит к генерации «однопоточного» плана выполнения запроса. Скорее всего, использование скалярных UDF (прим. переводчика: а для серверов младше 2008 R2 и не только скалярных) приведёт к тому, что ваш запрос будет выполняться в одном потоке (*грустно вздыхает*).

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

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

В своей статье я хотел бы рассказать о теории относительности. Эта теория не требуется в представлении. С самого своего создания она была окутана ореолом тайны, поскольку полностью подрывает наши привычные представления о пространстве и времени. Все мы в школе учили формулы теории относительности, но мало кто действительно понимал их. И это не удивительно, ведь человеку, чтобы по-настоящему понять какую-то теорию во всей её красоте, полноте и непротиворечивости, не достаточно знать формулы. Нужно иметь какой-то визуальный ориентир, нужна динамика, чтобы было что-то, что можно повертеть в руках. Я решил восполнить этот пробел и написал небольшую программку, в которой можно «повертеть в руках» пространство-время. Мы, как настоящие исследователи, с помощью небольших экспериментов попытаемся выяснить основные свойства этой загадочной материи.
Под катом много картинок (и ни одной формулы).

Здравствуй, хабрасообщество.
Идея данной темы для обсуждения пришла ко мне довольно давно, но поводом, толкнувшим к собственно тому, чтобы открыть редактор и написать текст, послужило недавнее собеседование. Но обо всём по порядку.

Введение

В 2009–2011 гг. я вёл проект системы управления знаниями (СУЗ) для одной довольно крупной компании. Собственно, этот проект сам по себе является поводом если не цикла статей, то уж двух-трёх точно. Именно в ходе реализации этого проекта я в полный рост столкнулся с одной огромной проблемой — мифологизации информационных технологий. Самое страшное то, что ей подвержены вроде бы взрослые люди, и даже временами выходцы из этой отрасли.

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

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

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

Добрый день, уважаемые хабрапользователи.

С недавних пор я занимаюсь разработкой на Ext JS 4 и Zend framework 2.

Пользуясь случаем, хотелось бы создать небольшую серию статей, «на пальцах» освещаюшую некоторые основные компоненты Ext JS 4, без которых не обойдется ни одно приложение на Ext JS (простите, серия,- громко сказано,- пишу из песочницы).

Итак, Grid, часть 1.

В то время как сторонники современных гибких методологий разработки выдумывают все новые и новые практики, их оппоненты также не стоят на месте. На фоне разнообразных XDD (FDD — Feature Driven Development, TDD — Test Driven Development, BDD — Behavior Driven Development, ATDD — Acceptance Test Driven Development) они сформулировали свою методологию — JSDD (Job Safety Driven Development). Кому интересны детали, добро пожаловать под кат.

Этот плод любви авиационной и банковской отрасли пережил вот уже более полувека. Однако его конец близок.

В 1967 году авиакомпании пользовались самолетами Боинг 727 и Дуглас DC-8, авиаперелеты были ещё чем-то особенным, а авиаперевозчики зарабатывали на этом большие деньги. Однако на горизонте появилась проблема. Авиакомпании собирались закупить первые широкофюзеляжные самолеты Боинг 747 и Дуглас DC-10, которые значительно увеличили бы пассажиропоток, а, следовательно, и число пассажиров, приходящих одновременно к стойкам регистрации. Для того чтобы предотвратить тот бардак, который мог бы из-за этого возникнуть, авиакомпании были вынуждены искать способ, который позволил бы ускорить процесс продажи билетов и регистрации пассажиров.

^{Фото: Леви Браун; Стилист-реквизитор: Ариана Салвато}

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

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

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

За долгое время работы в Яндексе нам удалось систематизировать все наши знания и огромный опыт в создании фронтенда веб-сервисов. Результатом этого осмысления и длительной работы стала первая Школа разработки интерфейсов, занятие которой шли в московском офисе Яндекса. Вся практическая часть обучения проходила в реальных проектах Яндекса. Теоретическая же состояла из лекций, которые читали ведущие разработчики интерфейсов Яндекса: Сергей veged Бережной, Михаил mishanga Трошев, Алексей doochik Андросов, Михаил azproduction Давыдов и другие.



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

Это мой первый пост на Хабре, поэтому не судите строго. Я достаточно много занимаюсь не только разработкой, но и постановкой процессов, в том числе тестирования. И всегда несколько скептически относился к ручному тестированию, точнее к той его части, которая отвечает за «обеспечение работоспособности существующей фунциональности» (в простонародье регрессионное тестирование). Что же плохого в этом тестировании и почему многие компании его тогда используют? Кто интересуется ответом на эти вопросы, могут потратить еще пару минут на дальнейшее чтение.

Итак, плюсики за статью типа "Платите программистам много" собраны, теперь самое время поговорить о том, почему это не работает просто математически, и что скрывалось за самым мелким шрифтом.

Понятно, почему это работает: распределение количества вакансий по зарплатам у нас очень похоже на нормальное, а значит у тех, кто находится справа от средней зарплаты, намного меньше возможностей найти зарплату выше, чем у тех, кто в левой части удава. Именно поэтому я написал, что ВЗ хоть и не мотивирует, но хорошо удерживает на текущем месте работы.
Но могут ли все работодатели воспользоваться этой «новой» и «работающей» методикой?

Эпиграф: Зарплата у меня хорошая, но маленькая!

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

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

Думаю, никто не будет спорить, что программный код должен быть чистым и «не пахнуть» (code smell), а паттерны проектирования и TDD должны стать верными спутниками любого мало-мальски грамотного разработчика на протяжении его нелегкой, но продуктивной карьеры. Все также знают, что цена ошибки в продакшине возрастает в десятки раз, а также то, что хорошие программисты оптимизируют код, а плохие — покупают новые сервера, а еще то, что 9 женщин не родят одного ребенка за месяц.



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

Мне часто задают вопрос: «Как ты находишь время?». Чаще всего речь идет об open source, иногда о книгах, изредка — о других вещах. Обычно я уклонялся от ответа чем-нибудь вроде: «Блин, не знаю, просто беру и нахожу». Но этот ответ не слишком полезен. Да и мне было интересно, смогу ли я справляться со временем еще лучше. Так что я немного порефлексировал, и вот как я нахожу время:

Уже некоторое время вверху моего сайта висит слоган:

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

Как и со многими (если не с большинством) из вас, со мной регулярно связываются рекрутеры. К сожалению, они не знают обо мне ничего конкретного, кроме того, что сумели найти в моем LinkedIn или GitHub. Если уж они и посещали мой сайт, то определенно не заметили этот слоган. Мне порядком надоело отвечать на тонны одинаковых писем (хотя возможно они чем-то и отличаются) снова и снова, так что, надеюсь, читатели моего блога на этот раз простят мне эгоистичное отступление от основной его темы.

Я разработчик софта из Луисвилля, штат Кентукки, и я здесь до чертиков счастлив.