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

Проблемы о которых не любят говорить на интервью, но с которыми приходится сталкиваться.

• Как успешно разрабатывать программное обеспечение вопреки трудностям?
• Понравится ли это начальству?
• Что за это будет?
• Как жить дальше?

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

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

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


Американец. Прожорливый, здоровенный, старый. Но тут уж рад и такому, машина не моя.

Есть у такого способа путешествовать несколько преимуществ и особенностей.

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

Нам очень хочется подарить всем нашим читателям какие-то подарки, но подарок у нас только один (зато хороший), поэтому мы решили разыграть его в небольшом конкурсе для программистов. Условия конкурса и описание приза — под катом. Задания не отнимут много времени, шанс выиграть есть у всех.

Сегодня, в эпоху социальных медиа, принято давать посетителям сайта возможность поделиться с друзьями. Мы делали промо-страницу к Дню Рождения интернет-магазина Allsoft и нам нужно было установить кнопки «Поделиться» от Facebook, Twitter, Одноклассников, Вконтакте и Мой мир.

С первого взгляда показалось — что может быть тут особенного — поставил готовый html/js код и готово? Но тонкости оказались в деталях: что если для одной соц. сети нужно передавать один текст, а для другой — другой? Как правильно передать картинку и описание во все сети? А если несколько разных вариантов текста и картинок на одной странице? Как почистить уже закешированную информацию о ссылке в соц.сети? На все эти вопросы нам пришлось найти ответы, которые и вы сможете узнать из этой статьи.

За 6 месяцев из PDF—презентации получился продукт. С привлечением посевных инвестиций, драйвом командной работы, путешествием в Нью-Йорк, изучением английского права, сложностями, открытиями, разочарованиями и вдохновениями. Вот так создавался Manifest.

Пост навеян этим вопросом в q&a. Вопрос хоть и не мой, но поностальгировать тоже захотелось.

Из описания к игре (текст 2002-ого года):
Двухмерная аркада с видом сверху, в которой присутствуют все оружие и многие вещи из QuakeII. Играть пока можно только по hotseat (два игрока за одним компьютером) и против бота. Есть разные карты (на 1 и 4 экрана), Вы сами можете их (карты) делать с помощью мэпедитора. Есть несколько моделей игроков (их Вы тоже сами можете делать с помощью mmodeler'a). Можно записывать и проигрывать реплэи игры.

Предыстория
Учился я в то время в школе, не помню уже, по какому поводу познакомился я в интернете с Константином Мухопад aka 3d[power]. После того, как он начал разработку своей игры Need For Kill, мне тоже захотелось сделать что-нибудь подобное. Недолго думая, я решил делать такую же игру, но с видом сверху. Вот только компьютер у меня был слабый и Q3 на нем не шел, поэтому делать я стал игру по мотивам quake 2.

Все большую популярность у гиков набирает развлечение в формате One-day Project или Funky Friday. Идея состоит в том, чтобы в очень сжатые сроки разработать и зарелизить проект. Польза состоит не только в том, чтобы почувствовать себя настоящим стартапером и проверить себя и свою команду на прочность. Польза в том, что такой формат позволяет проверить работоспособность идеи и найти подводные камни до того, как вы целиком посвятите себя проекту. Кроме того, дополнительный бонус в том, что вы научитесь разбивать идею на части, выделяя Самое Главное. Ведь за сутки невозможно, да и не нужно реализовывать все задумки — нужно сконцентрироваться на основном, чтобы успеть в срок.

Для нас это был второй проект, который мы разрабатывали в таком формате. С разработкой первого мы не уложились в сроки даже близко. Нас это научило лучше оценивать свои силы и подбирать инструментарий. К реализации второй идеи мы подошли более серьезно. Заранее была проработана идея, определен минимальный функционал и подобран инструментарий. Так что накануне, в четверг, на доске был разрисован план действий, распределены роли и выбран доставщик пиццы. Одним словом, все было готово к пятнице.

Друзья, я хочу вам рассказать историю развития проекта president2012.ru. Сайт является лидером по тематике выборов президента России, за 3 месяца его посетило около 2 млн. человек, в пике имел до 20 тыс. посетителей онлайн и более 1 млн. хитов в сутки, задействовано было 3 сервера облака.

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

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

Предисловие

Давно хотел написать. Мысли есть, желание есть, времени нету… Но вот нашлось, так что привет, Хабра.
Здесь я собрал все идеи, которые помогали и помогают в разработке веб-приложений. Для удобства я разбил их на группы:

1. Память
2. Оптимизация операций
3. Выделение критических участков
4. Циклы и объектные свойства
5. Немножко о DOM
6. DocumentFragment как промежуточный буфер
7. О преобразованиях в объекты
8. Разбитие кода
9. События перетаскивания
10. Другие советы

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

Память

Хоть это и не должно волновать клиентского программиста, но не забываем, что память всё-таки не бесконечна и когда-нибудь может закончиться, например, когда запущено несколько массивных программ: офис, графический редактор, компиляция большой программы и др. Несмотря на то, что приведенный пример тривиален, у меня действительно такое случилось, хоть и не из-за браузера, но он тоже сыграл свою роль: 1,3 Гб оперативы (отладчик, около 30 вкладок), начались тормоза по перегрузке страниц ОП в файл подкачки.
Чтобы уменьшить расход памяти, я предлагаю несколько способов:

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

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

Обфускация — это приведение исходного текста программы к виду, сохраняющему ее функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции. Применительно к JavaScript данная технология используется в таких видах теневого онлайн-бизнеса, как загрузки (iframe), спам и SEO. Наша задача на сегодня — изучить все методы скрытия JS-кода, которые, я надеюсь, ты будешь использовать только во благо.

Обфусцированный скрипт

Несколько минут назад началась продажа Indie Royale: The Really Big Bundle. В Really Big Bundle вошли следующие игры:

• Really Big Sky
• Runespell: Overture
• Cthulhu Saves the World
• Eufloria
• Бонус: Breath of Death VII

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

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

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

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

В продолжение предыдущего поста.


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

Путь о котором я говорю — путь «многорукого Шивы». Путь множества навыков и относительно малого знания. Те, кто переключился на путь знания идут вверх. Те, кто остался на пути навыков — остаются примерно там же, где и были.