Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

В продолжение статей о том, что ФАС собирает дополнительную информацию о «коротких» номерах, хочу рассказать, как эта служба может помочь вам избавиться от нежелательной рекламы по СМС.

Согласно ч.1 ст.18 ФЗ «О рекламе», распространение рекламы по сетям электросвязи, в том числе посредством использования телефонной, факсимильной, подвижной радиотелефонной связи, допускается только при условии предварительного согласия абонента или адресата на получение рекламы.

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

Обнаружил очень необычное тестовое задание, вот его текст:

«Взгляните на приведенную ниже функцию. На первый взгляд, как вам показалось, что она делает? Что в ней не так?

Внимательно ознакомьтесь с кодом функции.

Какие потенциальные недочёты и неудобства вы в ней обнаружили?

Каким образом целесообразнее всего произвести рефакторинг или спроектировать код заново? (если это нужно, на ваш взгляд, сделайте это).»

Занимаясь одбором кандидатов на вакансию программиста, столкнулся с проблемой — подобрать хорошее тестовое задание. Цель — увидеть, программист ли передо мной или человек, хорошо знающий фреймворк\язык\технллогию. Поясню — программист, это человек, которые может решить нетривиальную проблему. Сделать сайт-блог, даже e-commerce сейчас является тривиальной проблемой, на это способен любой junior. Natural-born программистдумает по-другому.

под катом образец тестового задания

Кандидаты — «Senior PHP», с опытом, до собеседования проходят первичный отбор по резюме\сопроводительному письму, то есть на собеседование попадают лишь те, кто выглядят как приличные программисты. Собеседования проводятся удалённо — Skype/ICQ (без голоса). Т.е. теоретически можно гуглить, хоть я и прошу этого не делать.

Итак, тесты, которые отсетвают «типа программистов»:

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

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

Жизнь мальчиков с математическими способностями в атомных городах была предопределена — школа с пятерками по алгебре и геометрии, мех-мат столичного университета, возвращение в систему, квартира через год, кандидатская степень в 40 лет, ВАЗ 2103 к пятидесяти годам, звание доктора, гараж, шесть соток, четыре квадратных метра.

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



Далее я проваливаюсь в историю компьютерной игры.
Под тегом личные воспоминания ветерана без ссылок, рекламы, картинок и кода.
Спасибо за чудесные комментарии, парни.

Вы заботитесь о своем здоровье?

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

Что оказалось непросто. В данной статье я расскажу о моем способе организации «правильного» рабочего дня, о том, что следует для этого делать, и где лежат грабли, на которые нельзя наступать. Тема «компьютер и здоровье» уже несколько раз поднималась на Хабре, поэтому я задумывал этот пост как статью, которую можно добавить в закладки и использовать в качестве «руководства к действию».

А у вас есть визитка?

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

Креативные визитки

Программист

Недавно участвовал в разработке одного проекта — фото конкурса. По задумке, рейтинг фото альбомов должен формироваться из суммы всех публикаций в социальных сетях: Facebook, Вконтакте, Twitter. Т.е. общий рейтинг фотоальбома расчитывается:

Рейтинг фотоальбома = кол-во «Share» в Facebook + кол-во «Сохранить» в Вконтакте + кол-во «Retweet» в Twitter

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

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

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

Итак:

• количество лайков будем получать от REST сервисов каждой социалки
• кнопки рисуем свои и обрабатываем событие click

Прочитал немало статей на Хабре на тему «вовремя ложиться и вставать и не спать потом целый день», больше всего понравилась статья "Спать мало, но правильно".

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

Вот они:

Все знают как хороши ёмкостные экраны в iPhone и других аналогичных девайсах и как неудобно использовать их в холодное время года.
Приходится по любому поводу снимать и надевать перчатки.
Сегодня во время прогулки мне наконец то надоело мерзнуть набирая на ходу что-то в ICQ или в СМС.
Или жонглировать перчатками слушая подкасты, отвечая на звонки и т.д.
Немного подумал и решил снять эту проблему для себя сразу по приходу домой, просто немного улучшив свои перчатки из флиса. Но можно так переделать и любые другие перчатки.
Под катом мое решение проблемы.
У кого трудности с заявленным материалом, читайте последний абзац топика, там предложены другие конкурентные решения!

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

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

Проблема

Не так давно мне потребовалось обновить своё резюме. Последний раз я это делал несколько лет назад, так что решил написать резюме с нуля.

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

Каждый программист — проектировщик API. Хорошие программы состоят из модулей, а протокол взаимодействия модулей — это тоже API. Хорошие модули используются повторно.

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

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

API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

Дисклеймер: если после прочтения этого текста вы захотите внедрить KPI для программистов — сходите прочитать еще и это.

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

Итак, какие цели преследует аттестация.

Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

Если гонится за вами
Слишком много человек,
Расспросите их подробно
Чем они огорчены?
Постарайтесь всех утешить.
Дайте каждому совет,
Но снижать при этом скорость
Совершенно ни к чему.
Г. Остер

Сегодня чудесный весенний день. И не только потому что он весенний и очень скоро кому-то придется ехать на дачу копать картошку. А потому что сегодня версия 2.1 API Яндекс.Карт перестает быть beta-версией и становится основной.

К этому событию мы полностью обновили документацию, добавили новых примеров в песочницу и написали эту статью. В этот раз мы решили не рассказывать только про версию 2.1, так как про нее мы уже и так достаточно поговорили во время запуска беты. Поговорим об использовании API Яндекс.Карт в целом.

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

Некоторые вещи часто делают неправильно. Сегодня я хочу о них рассказать. Все советы, которые вы прочтете — вредные. Если вы поймете, что соблюдаете некоторые из рекомендаций этой статьи, ничего страшного – никогда не поздно сделать ваш проект немного лучше. Итак, Irony mode ON.

Это перевод статьи Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE Скотта Хансельмана за 30 марта.

Прочитал сегодня пост на ArsTechnica «Я знаю слишком много чтобы программировать быстро. Что мне делать?» — это обзор вот этого вопроса на StackOverflow:

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

Простой пример: раньше я просто записывал данные в файл. Теперь я думаю о правах доступа, занятии файла другим приложением, многопоточности, атомарных операциях, фреймворках, разных файловых системах, количестве файлов в директории, предсказуемых названиях временных файлов, качестве моего ГПСЧ, отключении электричества во время любой операции, адекватном API для моего кода, нормальной документации и так далее.

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