Всем привет! Меня зовут Андрей, я работаю в отделе разработки продуктов Veeam Software.

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



Сегодня я хочу рассказать свою историю.

Итак, начну с момента, когда мне исполнился 21 год, я уволился из рядов доблестной российской армии и оказался на серых и холодных улицах Санкт-Петербурга. Осень, отсутствие жилья и денег активировали все клетки головного мозга для ответа на вопрос: «Что делать?».

Если вы регулярно используете 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. Быстрый поиск плохого коммита

В Петербурге зарплаты для Java-junior'а колеблются от 30 до 60К рублей. За пару лет реально дорасти до 80К, за 3-4 года — до 120К. Это докризисные цены, сейчас многие подняли зарплаты еще процентов на 20, сначала те, у кого клиенты зарубежные, а потом и остальные, чтобы оставаться конкурентноспособными.

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

Я уже несколько лет наблюдаю за поведением IT-студентов с большим интересом. Получается, что после университета у них либо есть нужная хорошая практика как старт; либо же они оказываются перед чертовски странным выбором, где даже непонятно, что и из чего выбирать. И по книгам, Гитхабу или другим самостоятельным образом выучиться достаточно быстро не выйдет — очень много времени будет потрачено просто зря. При этом в мире нужны все: дикий кадровый голод на Java-программистов есть по всему миру. Количество программистов в мире растет на 15% в год то есть, удваивается каждые 5 лет, а в России — еще быстрее. У бизнеса огромный спрос на прогеров. Понятно, что ВУЗы просто не успевают подготовить такое количество кадров.

Надо что-то с этим делать. И вот к каким выводам в Java User Group мы пришли по этому поводу относительно студентов.

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

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

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

Наверное не ошибусь, если предположу, что какая-то часть хабра-сообщества помнит это мероприятие, которое проходило в Москве, Киеве, Ростове-на-Дону, Тбилиси, Ташкенте, Иркутске, Магнитогорске, Ленинграде и Минске.



Лично для меня с него началось мое знакомство с высокими технологиями, хотя придя туда, увидел достаточное количество сверстников, оккупировавших компьютеры своими болгарскими 5-дюймовыми дискетами, а как пишет New York Times за 6 июня 1987 года, некоторые уже пытались уломать гидов скопировать им Lotus 1,2,3. Итак,

После того, как у меня появился новый монитор на рабочем месте, я начал новую итерацию улучшения своего «безмышечного» (mouse-less, прим. пер.) опыта. Вы же знаете, что это значит, не так ли? Это значит, что каждый раз, когда вы беретесь за мышку, убирая руку с клавиатуры, вы тратите немного времени и энергии. Если вам нужно набирать много текста (а я много пишу кода), это становится существенным.

Так же существует следующий уровень «безмышечного» опыта, когда вы стараетесь избежать труднодоступных клавиш, например Delete, Backspace, Escape или даже Enter.

Если вы держите руки в стандартной позиции для 10-пальцевой слепой печати, более удобно нажать Ctrl-m вместо того, чтобы тянуться мизинцем к энтеру.

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

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

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

Существуют различные мнения относительно производительности С++ и C#.

Например, сложно поспорить с тем, что код C# может работать быстрее за счет оптимизации под платформу во время JIT компиляции. Или например с тем, что ядро .Net Framework само по себе очень хорошо оптимизировано.

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

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

Попадались и утверждения о том, что код на С++ примерно в десять раз быстрее кода на С#.

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

Уважаемые читатели, в этой статье я хочу рассказать о таком важном средстве многозадачного программирования среды .NET, как многопоточность. Данная статья содержит начальные сведения, и предназначена для быстрого освоения азов многопоточности на языке C#. Однако не буду разглагольствовать о преимуществах параллельного выполнения задач, и перейду к примеру кода.

Добрый день, хабраюзер!

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



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

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

Наша команда проверяет большое количество открытых проектов, чтобы продемонстрировать возможности анализатора PVS-Studio в нахождении ошибок. После наших статей нередко звучит вопрос «Как же программа работает с этими ошибками?». Попробую на него ответить.

Перед разработчиками довольно часто встаёт выбор — сделать всё правильно, потратив на решение задачи уйму времени, или сделать так, чтобы работало, не особо вдаваясь в детали того, как именно это получилось. Со стороны заказчика, разумеется, наиболее привлекательной является некая золотая середина, которая в данном случае заключается одновременно и в хорошем понимании программистом выполненного таска, и в как можно меньшем количестве затраченных на него человеко-часов. С разработчиками тоже не всё так однозначно — с одной стороны, понимать, что происходит в своём собственном коде, это вполне естесственное желание (особенно если поддержка данного продукта также будет лежать на его плечах), а с другой стороны, если результаты работы приложения представлены в наглядном виде (графики / звуковые или видео-фрагменты etc), разработка разовая, и отдел тестирования говорит, что всё хорошо, то почему бы не проскроллить оставшуюся часть рабочего времени Хабр, посвятив время себе любимому?

Ближе к делу. В одной из предыдущих статей я уже упоминал о программе под названием «Говорилка». Несмотря на название, сама по себе она ничего не озвучивает, а лишь является связующим звеном между пользователем и речевыми движками, предоставляя более удобный интерфейс и возможность конфигурации. Одним из наиболее популярных в узких кругах движков является «Digalo 2000 text-to-speech engine» (далее — Digalo), ссылку на который можно найти как раз на сайте «Говорилки». Как вы уже, наверное, догадались из тематик моих предыдущих статей, не всё с ним так хорошо, и без багов тут также не обошлось. На этот раз проблема проявилась при озвучивании текста «ааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааа». Немного поэкспериментировав, я обнаружил, что при достижении определённого количества «неразрывных» символов Digalo начинает крашиться, предлагая отладить свой процесс. Ну, а что, почему бы и нет?

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

Я — программист. А ещё я слеп. Слеп, как крот, как говорится. Таков я от рождения.

Когда я говорю об этом своим товарищам, то те из них, у кого никогда не было проблем со зрением, обычно задают один из трёх вопросов:

• Как же ты тогда можешь читать то, что я пишу?
• Ого. А как ты тогда можешь кодить?
• Или — самый популярный вопрос — А ты видишь сны?

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

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

Данный способ я назвал «блочным» (оговорюсь, что многие термины в статье были придуманы мной, так как материалов на данную тему на русском нет; после исследования нескольких игр я занялся изучением англоязычных материалов и документации к редакторам игр для старых платформ, тогда уже нашлись некоторые аналогии, в таких случаях буду приводить свои термины с объяснением их значения и их английские версии). В качестве примеров я буду приводить уровни из игры «Darkwing Duck», а также других игр компании «Capcom», разобранных мной несколько лет назад.

Я постараюсь пропустить описание использования дизассемблера и техническую часть исследования (если будет интерес, можно сделать на эту тему отдельную статью), а остановлюсь на описании, как именно разработчики хранили данные. Зная, что именно искать, найти это внутри образа ROM станет намного проще. Бонусом я покажу готовый редактор уровней и несколько созданных на нём хаков классических NES-игр.

Доброго времени суток %username%.

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

Как некоторым известно, я очень люблю язык Go ну, и решил попробовать написать на нем. Что из этого получилось — под хабракатом.

Part 0x00
Part 0x01

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

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

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

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

Многие игры были рассмотрены на сайте Fabien Sanglard. Если вам интересны подробности их работы, то пожалуйте к нему.

Можно заметить, что многие игры принадлежат id Software/Apogee. Совпадение? Не думаю. id славится открытостью и привычкой выпускать исходники. Старые коммерческие игры уже не имеют ценности и были бы потеряны – не лучше ли, чтобы кто-то учился чему-то полезному на их основе?

Итак, приступим (в хронологическом порядке):

Приветствую всех Хабровчан!

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


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

Те, кто уже сегодня сделал backup, добро пожаловать под кат.

Редко бывает, что одна лишняя буква в названии стандарта грозит совершить революцию в мире интерфейсов передачи данных и гаджетов, но появление последней разновидности USB 3.1 Type-C похоже как раз тот случай. Что же нам обещает принести очередное обновление старого доброго USB интерфейса?

• Скорость передачи данных до 10 GBps
• Возможность запитывания от порта устройств с потребляемой мощностью вплоть до 100Вт
• Размеры коннектора сравнимые с micro-USB
• Симметричность разъёма — у него не существует верха и низа, а значит нет ключа, который часто приводит к повреждениям как самих разъёмов, так и подключаемых через них гаджетов
• С помощью данного интерфейса можно запитывать устройства с напряжением вплоть до 20 вольт
• Больше не существует разных типов коннекторов — А и В. На обоих концах кабеля стоят совершенно одинаковые разъёмы. Как данные так и питающее напряжение могут передаваться через один и тот же разъём в обоих направлениях. В зависимости от ситуации каждый разъём может выступать в роли ведущего или ведомого
• Нам обещают, что конструкция разъёма способна выдерживать до 10 000 подключений
• Возможно использование этого интерфейса для непосредственного подключения вместо некоторых других широко распространённых интерфейсов для быстрого обмена данными.
• Стандарт совместим сверху вниз как c обычным USB 3 интерфейсом, так и с его младшими братьями. Конечно не на прямую, но с помощью переходника через него возможно подключение скажем USB 2.0 диска

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

Когда результат SQL-запроса влечет бесконечные приведения типов ко всевозможным вариантам типов полей. Когда код заполнен малопонятной логикой с гигантским перебором перегрузок по типам boost::variant. Когда не знаешь, как принять аргумент произвольного типа по RPC-протоколу. Тогда требуется механизм эмуляции динамической типизации в C++. Расширяемый и удобный, создающий понятный API. Такой, что не требует предопределенного списка типов и не заставляет работать с указателями на базовый класс. Такой механизм есть — нам поможет двойная диспетчеризация!