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

Пролог: Концепции Boost
Часть 2: Завершаем реализацию поддержки концепций

Потребовалось недавно алгоритм поиска пути для нашей игры переделать. Прошлый был полностью самописный — шаг в сторону, и все плохо… Захотелось взять готовый из хорошего источника. Тут-то и вспомнилось, что в boost есть функциональность для работы с графами. К сожалению подход, «найди функцию, вызови — и все заработает» не состоялся. Упор в библиотеке сделан на максимальную гибкость использования, что негативно сказалось на простоте. В то же время и ничего смертельного — все лучше, чем с нуля делать (и потом исправлять). С другими библиотеками тоже связываться желания не было, в то время как boost в проекте используется давно…

Среди документов опубликованных Эдвардом Сноуденом, бывшим сотрудником ЦРУ и Агентства национальной безопасности США, были обнаружены материалы описывающие некоторые детали технологий шпионажа используемых АНБ. Список программных и аппаратных средств оформлен в виде небольшого каталога. Всего сорок восемь страниц отмеченных грифами «Секретно» и «Совершенно секретно», на которых дано краткое описание той или иной технологии для слежки. Данный список не является исчерпывающим. Представлены техники связанные с получением скрытого доступа к вычислительной технике и сетям, а также способы и устройства радиоэлектронной разведки связанные с мобильной связью и оборудование для наблюдения. В этой статье я расскажу об этих методах шпионажа, далее будет четыре дюжины слайдов(осторожно, трафик).

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

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

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

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

Начну с истории о программистах, которую мне приходилось слышать неоднократно.

Я попросил Джо написать простенькую программу, которая делает <xyz>. Работы там было на несколько часов, в худшем случае на день. Ему понадобилось несколько дней, за который он написал гораздо более сложный фреймворк, чем требовалось. Почему он снова так намудрил?

Возможно, дело в том, что Джо – Абстрактно ориентированный программист (АОП).

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

Настоящие размышления о программировании посвящаются главе 33 “Личность” и тем, кто решил связать свою жизнь с разработкой программного обеспечения.

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

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

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

20 основных причин провала старапов по версии ToWave

Хотите получить представление о том, как устроен boost::function, boost::any “под капотом”? Узнать или освежить в памяти, что скрывается за непонятной фразой “стирание типа”? В этой статье я постараюсь кратко изложить мотивацию, стоящую за этой идиомой и ключевые элементы реализации.

О переводе

Это перевод 18 главы книги The Passionate Programmer: Creating a Remarkable Career in Software Development. Её автор — Chad Fowler — талантливый Ruby-разработчик, известный докладчик на конференциях, посвящённых Ruby и IT в целом. Бывший саксофонист, а сейчас — CTO 6Wunderkinder.


Краудсорсинговый перевод книги ведётся на github, присоединяйтесь.

Всего лишь рассказ о 5-ти, по-моему, интересных книгах.

Привет, {{habrauser}}.

Скоро долгожданные новогодние выходные, и ты, наверное, уже спланировал, как их провести. Игры, горы, поездки, телевизор (серьезно?). Для себя решил, что хочу сделать карьерный рывок и просто научиться делать лучше, то чем сейчас занимаюсь — управление интернет-проектами. Надо сказать, учиться в моем (28) возрасте довольно тяжело. Если в школе или ВУЗе знания еще ровно ложились на пустой лист моего опыта, привычек и понимания, то сейчас все иначе. Учеба — это процесс внутреннего изменения, я должен переписать существующие знания новыми. Начать делать что-то иначе. Но и награда велика — новый результат, новый опыт, расширение сознания, да и просто жить так интереснее.

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

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

К сожалению, во многих случаях авторы либо забираются в недосягаемые выси многослойных архитектур, что требуется в лучшем случае для 1% проектов, либо ограничиваются общими фразами вроде «код должен быть понятен» или «используйте ООП и паттерны», не опускаясь до подробных объяснений, в чем например измеряется «понятность» кода.

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

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



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

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

Сегодня, 20 декабря прекратилась поддержка Winamp — самого узнаваемого и родного для многих музыкального плеера. Последней стала версия Winamp 5.66. В память о времени, проведённом вместе, мы сделали тематическое оформление для страницы Яндекс.Музыки. Найти его можно здесь — music.yandex.ru/oldschool.



Мы разложили треки в папки с жанрами: панк, рок, металл, эстрада, поп, классика, кантри, регги, джаз и т.д. В папке с музыкой 90-х — E-Type и Иванушки International, Haddaway и Игорь Тальков, R.E.M и тот самый ранний «Мумий Тролль», Matchbox Twenty и ЧайФ. Остальные папки тоже не пустые. Мы собрали даже музыку «на будильник». Будем пользоваться и вспоминать.

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

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

У нас на заборе бумаге написано очень много букавок о том, как управлять проектами. Столько же, если не больше закорючек посвящено тому, какие истории успеха из этого выходили. Тошнотно, неинтересно, задолбало. Рассмотрим историю одного провала, это ведь всегда интересней и притягательней (видимо, в силу натуры человечьей больше злорадствовать, чем радоваться). Приступим.

— Багнутый диван! — чертыхнулся Антон, в очередной раз придавив пальцы тяжеленным диваном, который они с Сергеем тащили уже 14 пролётов.
— Багнутый? — переспросил Сергей, — ты тоже программистом раньше работал?
Они уже почти месяц работали вместе, но Сергей ни разу не заподозрил в нем бывшего программиста. Жилистый, мускулистый Антон как-то мало походил на бывшего программиста.
— Приходилось подрабатывать в студенческие годы, — немного сконфузившись ответил Антон.
— Да не дрейфь! Я свой. Три года вёрстки и js под все браузеры, — Сергей оживился и надавил чуть сильнее, придавив Антона.
— Тише ты! Штука тяжелая! Из-за нее у меня уже функционируют только 7 пальцев. И вообще тут лучше о кодопрошлом разговаривать вполголоса. Настучат — вмиг вылетим с работы. Фуух, какой тяжелый! Двигай влево до упора.

Для некоторых мне известны возможные решения. Некоторые изредка встречаются на собеседованиях, реже чем об обедающих философах. Интересно было ознакомиться, как развлекаются в МассТехе.

Не мог пройти мимо топика "Вопросы на собеседование middle/senior iOS Developer" и статьи "Собеседование разработчика". Хочу предложить альтернативный или дополнительный подход к собеседованию разработчиков.

Разбор говнокода или сотня разношерстных вопросов на листочке — это, конечно, прекрасно, но если это единственный этап собеседования, то это вызывает желание спросить что-то вроде: «Вы серьезно?»

Вы не устали от того, что на собеседованиях на конкретную позицию разработчика вас спрашивают достаточно сильно оторванную от жизни фигню, которую хочется поскорее забыть после такого собеседования (режим nightmare — это тест на 150+ вопросов и психолог в конце)? Я не отрицаю, что оценивать качество кода — это очень важно, но оценивать качество какого-то конкретного куска и делать по нему большие выводы — это точно неправильно.

К тому же, слишком много так называемых разработчиков не имеют никакого понятия о том, как строить архитектуру приложения, как грамотно разделить компоненты на модули, как внести гибкость для последующих изменений проекта. А вопросы подобные вопросам из топика "Вопросы на собеседование middle/senior iOS Developer" не дадут вам понять, насколько человек хорошо применяет свои знания при реализации проекта.

Что ты предлагаешь, чувак?

Давайте рассмотрим на примере android разработчика (адаптировать можно для любой области, но вы же понимаете, что без конкретики эту статью просто раскритиковали бы, так что поговорим об android).

Что я предлагаю: берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение и беседуем насчет того, как кандидат бы его сделал!

Почему это хороший вариант? Вы сможете достаточно точно оценить уровень разработчика в проектировании и реализации ПО, его знание платформы и другие важные вам ньюансы, а так же просто приятно провести время (в случае с компетентным кандидатом, да и ему будет интереснее чем на типичном собеседовании). + Вы сможете понять, насколько человек общителен, как вольется в вашу команду, сможет ли он объяснять свои решения другим?

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

Для примера, возьмем приложение Вконтакте для android (оно большое, сложное и многим знакомое).

Этот текст был задуман как попытка структурировать основные принципы успешной технической поддержки и общения в целом. Под «успешной» в данном контексте подразумевается положительная реакция непосредственно клиента на качество сервиса, т.е. его конкретное субъективное мнение по итогам обращения в техподдержку.

Немного об авторе: никакого психологического образования не получал, курсов общения с клиентами не проходил, так что все выводы основываются исключительно на личном опыте. Я начал работать в технической поддержке более 8 лет назад, в компании Acronis, тогда еще совсем небольшой, а штат техподдержки не превышал 10-15 человек. Сегодня в техподдержке участвует более 250 человек, поддерживая клиентов на девяти языках мира. Со временем я прошел все этапы — от работы в небольшом коллективе с практически нулевым уровнем личной ответственности до контроля и взаимодействия в большой инфраструктуре, включающей автоматический сбор статистики по каждому сотруднику для замеров его личного KPI (key performance indicators).

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