Несколько лет назад я был студентом без денег, которому учеба в университете казалась скучной и бессмысленной (и с тех пор моё мнение не изменилось). Так что, учебу я бросил и стал фрилансить. Спустя 6 лет, пишу этот текст, чтобы определить самые важные идеи, которые сделали меня сначала хорошо оплачиваемым “кадром”, а затем руководителем небольшой команды разработки веб-сервисов.

Не будьте специалистом. Учитесь действовать

Главный ресурс для развивающегося человека вовсе не знания и опыт. И даже не деньги или связи.

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

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

Доброго времени суток читатель.

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

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

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

Для тех кому интересны подробности — прошу под кат.

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

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

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Целью данной заметки я ставлю в подробностях описать организацию сервера для Rails приложений в самой популярной на данный момент связке: rvm + Rails + Nginx + Unicorn. К написанию статьи побудило отсутствие полной пошаговой документации по этой связке, понятной не только ядреным профессионалам этой области. Далее я попытаюсь подробно, шаг за шагом, описать идеологически правильный процесс организации сервера для обслуживания нескольких Rails приложений (на примере одного) — если у вас есть абсолютная уверенность в том, что на подопытной машине никогда не будет работать более одного приложения — настройка может быть существенно короче и проще. Хочу предупредить, что тонкости, касающиеся работы приложения под высокой нагрузкой в статье не описываются, т.к. цель ставилась иная — заставить работать приложение в связке и сократить количество конфликтов с другими приложениями до минимума.

В конце июля Президент подписал законопроект о внесении поправок в федеральный закон «О персональных данных». Закон этот был опубликован в "Российской газете" 27 июля, и тогда же вступил в силу. Вдобавок, ему придана еще и «обратная сила»: действие его распроостраняется и на те правоотношения, которые возникли с 1 июля. Принятию предшествовала бурная дискуссия: несколько специалистов в области информационной безопасности обратились к Президенту с открытым письмом, в котором призвали его закон ни в коем случае не подписывать. По мнению подписантов письма, предлагаемые поправки не соответствуют конвенции Совета Европы «О защите физических лиц при автоматизированной обработке персональных данных», хотя целью проекта было именно выполнение ее требований.

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

Читатели помнят, что ещё в декабре прошлого года, после публикации пользователя brunql мы с ним и timsat решили всерьёз взяться за open-hardware проект, который назвали Лайтпак. В феврале мы даже презентовали вам ревизию 4.3 после которой к проекту присоединилось много светлых голов.

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

Привет, %хаброюзер%!

Сегодня я поделюсь с вами своим опытом прохождения собеседований на вакансии PHP-программиста в «белокаменной»Москве.

Сколько слов в английском языке? Oxford English Dictionary содержит около 500 000 словарных статей, не учитывая специфические научные слова и выражения (которых насчитывается еще порядка 500 000). А как вы думаете, какой средний словарный запас иностранного языка дает вам средняя школа за время обучения? Правильный ответ – около 2500 слов. Мало ли этого набора? Тут уже надо исходить из ваших целей. Для общения с иностранцами на деловые темы – однозначно мало. Для чтения несложных текстов в интернете – более чем достаточно. Если быть точнее:

400–500 слов – активный словарный запас для владения языком на базовом (пороговом) уровне.
800–1000 слов – активный словарный запас для того, чтобы объясниться; или пассивный словарный запас для чтения на базовом уровне.
1500–2000 слов – активный словарный запас, которого вполне хватит для того, чтобы обеспечить повседневное общение в течение всего дня: или пассивный словарный запас, достаточный для уверенного чтения.
3000–4000 слов – в общем, достаточно для практически свободного чтения газет или литературы по специальности.
Около 8000 слов – обеспечивают полноценное общение для среднего европейца. Практически не нужно знать больше слов для того, чтобы свободно общаться как устно, так и письменно, а также читать литературу любого рода.

К этим данным пришел известный шведский полиглот Эрик Гуннемарк, основатель Международной ассоциации `Amici Linguarum` (`Друзья языков`). Более того, он составил набор минимального количества слов и выражений, которые необходимо знать, для порогового уровня владения языком, назвав их Минилекс и Минифраз.

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

С 2008 года компания Google ведёт разработку открытой (open source) технологии Native Client, которая позволяет запускать x86-код в браузере, с ограничениями безопасности, как у JavaScript. Не нужно объяснять, что благодаря Native Client появится новое поколение браузерных приложений с прямым доступом к ресурсам центрального процессора. В каком-то роде это именно то промежуточное звено, которого не хватало между нативными приложениями и веб-приложениями.

Два с половиной года Google работал над тем, чтобы устранить проблемы с безопасностью Native Client, и вот наконец-то это свершилось: вчера Native Client включён в состав последней беты Google Chrome 14.

Приложения Native Client используют программные интерфейсы Pepper (PPAPI), которые являются апгрейдом Netscape Plugin API (NPAPI) — технологии, используемой в большинстве браузеров, кроме Internet Explorer (ActiveX).

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

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

Смотря на новую соцсеть Google+ (которая в целом мне очень нравится), я силюсь понять, что мешало российским гугловцам использовать такие же смелые и яркие названия, как в английской версии. Что мешало перевести Sparks как Вспышки? Но нет, мы получили сухие и незапоминающиеся Темы. А ведь там даже иконка сделана в виде вспышки. Теперь эта визуально-смысловая связь утрачена.

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

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

Всем привет!

На днях я делал интеграцию своего сайта с платежными системами для отъёма денег у населения. Решил поделиться своими наблюдениями по поводу качества работы и быстроты настройки некоторых систем.

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

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

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub'а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

Эта статья ставит целью описать решение одной нетривиальной задачи — автоматическая односторонняя синхронизация данных в базах двух проектов средствами Ruby on Rails, гема legacy_migrations и относительно прямых рук.

Исходная ситуация

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

Как написал у себя в твиттере один из наших партнеров: «Напиши лет пять назад «молния вызвала падение облака» и тебя бы посчитали идиотом». Но именно это и случилось в воскресенье вечером – молния попала в трансформатор, что полностью обесточило датацентр Amazon в Ирландии. К сожалению, сайты компании «1С-Битрикс» находились именно в этом датацентре.



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

И сегодня хотим рассказать вам о том, «как это было», о наших действиях и выводах, которые мы сделали после данного инцидента.

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

img:not([width]):not([height]) {
  border: 2px solid red !important;
}

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

Оригинал статьи

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

Привет Хабр,
Меня вводит в ступор С++. Вот просто, зависаю над монитором, смотрю в окно, попиваю чай… И начинаю жалеть за бесценно проведенные годы за изучением стандарта С++, попытками написать свой фронт-энд компилер. Эти мудреные книжки С++ In Depth. Как же я негодовал, когда не понимал кода из книги Александреску. Как записывал все постулаты Страуструпа и иже с ними. Зачем? Вот спрашиваю себя, зачем я теперь все это знаю. Более, я хочу сказать, что этот язык нещаден для гуру, не с медицинской, не с экономической точки зрения! Он не оправдывает усилий, вложенных в его изучение — раз. На практике, он экономически не выгоден — два. И нервные клетки подтвердят, что сопровождать чужой плюснутый код — бывает опасно для здоровья -три. Пусть тут будут рандомно разбросаны метафоры, пишу как есть, из опыта.