Пьеса «Технический долг» в 9 частях. Ставится и показывается впервые.

Часть 0: В пустой комнате стоят Разработчик (Р) и Менеджер (М).

М: Я собрал нас тут, чтобы рассказать пренепреятнейшее известие: система КРОТОПОН, которая работает на продакшане заглючила и мы потеряли кучу денег. Кроме того нет никого, кто знает как она работает. Поэтому (с придыханием) наш СЕО дал мне священную миссию — написать новую систему. Как ты думаешь, за два месяца справишься?

Р: А что делать-то нужно?

М: Да там немного, всего лишь пару десятков систем связать и рюшечки навесить.

Р: Эй, да это же на год работы! И вообще требования будут?

М: (В телефон) Да, конечно, за пол года справимся. (Разработчику) Ну ты тут пока начинай, а я тебе требования потом донесу.

Менеджер уходит.

Р: Но тут же…

Разработчик тяжело вздыхает, затаскивает в комнату инструменты и начинает что-то сооружать.

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


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

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

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

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

Эта статья – часть серии «Как написать резюме». Чтобы начать серию сначала, прочитайте введение.

За свою жизнь, я использовал несколько плохих слов. Даю %^й на отсечение, что вы тоже делали это. Но, когда неправильные слова появляются у вас в резюме – это делает его отстойным.

Свой собственный сленг рано или поздно образуется в любой команде. Айтишный же, наверное, складывается на 90% из словечек, которые более-менее понятны любой другой компании-разработчику, особенно в контексте. А на 10% — из особенностей фунциональности разрабатываемого продукта или конкретного разработчика.
Под катом – профессиональный словарик девелоперов Parallels. А какие у вас в команде крылатые выражения?

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

Встречаются два друга:
— Как дела?
— Да вот, основал новый стартап, очень быстро растём, развиваемся.
— Круто! А в чём суть стартапа?
— Я провёл исследование рынка и решил публичный дом открыть.
— Ого, интересно, и какие цены?
— Анал — $100, орал — $50.
— А классический секс?
— Понимаешь, это ж стартап. В общем, я пока один работаю…

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

Салют, Хабр!
Недавно я уволился с довольно завидной должности (главного архитектора) в довольно неплохой компании (Acronis) и с непоколебимым решением в мозгу больше не работать по найму переехал из Москвы обратно в Ереван, откуда семь лет назад понаехал в Златоглаво-Нерезиновую. Учитывая необычность произошедшего и часто задаваемый вопрос «но почему?!», я решил разобраться в собственных мыслях и озвучить их вслух для себя самого и тех, кто может почерпнуть в моих размышлениях что-то для себя полезное. Короче говоря, это рассказ о том, почему я оставил высокооплачиваемую перспективную работу в международной компании ради сомнительной перспективы начать собственное дело, и как я собираюсь дальше жить.

Штатная десериализация .net всегда создает граф новых объектов. Это не всегда удобно.

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

Поиск не дал готового ответа. Есть не самые простые решения с использованием protobuf и прочих сторонних сериализаторов, но это не всегда применимо.

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

На днях, после долгого перерыва, надо было поработать на WPF, и возникло желание заменить поднадоевший стандартный вид окон Windows 7 на что-нибудь более вдохновляющее, скажем в стиле Visual Studio 2012:

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

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

Настройка IPv6-туннеля за симметричным NAT и удаленного управления через VNC

Не так давно я искал решение для удаленного администрирования системой на Linux. Основная проблема в том, что подключен к интернету через провайдеров, использующих симметричный NAT. То есть из internet машины не доступны. Если поискать, то можно найти некоторые программы для удаленного администрирования, но как правило они немало стоят. Опишу, как можно сделать доступ снаружи без таких программ с помощью IPv6-туннеля через gogonet и VNC.

О чем речь?

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

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

1) AutoMapper
2) BLToolkit
3) EmitMapper

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

В статье рассказывается про ручную сборку базы данных PostgreSQL для 1C под Gentoo Linux.
Не буду рассказывать о всех тупиковых ветвях нашего лабиринта сборки постгреса для 1С. Опишу только то, чего нигде в интернете нет — то, что мы раскурили методом научного тыка. Несмотря на обилие мануалов по установке постгреса для 1C, ни один из них не решил наших основных граблей, все они оказались поверхностными и ничего не объясняли. Поэтому мы посчитали своим долгом восполнить этот пробел :-)

Преамбула.

В связи с бурным развитием мобильных устройств и ОС Google Android в частности, интерес к разработке программного обеспечения под данную платформу весьма закономерное явление. Как оказалось, он мало чем отличается от обычной разработки на Яве под десктоп/веб, а с учетом возможности использования «стандартного» IDE (Eclipse) путем скачки и встраивания SDK Андроида, а также наличия исчерпывающей документации многие технические вопросы снимаются сами собой. Концептуальный аспект (т.е. идея для реализации в виде ПО) также не заставила себя ждать, благо платформа сравнительно новая, не смотря на недавно вышедшую уже версию 2.1, и конкурентная среда соответственно не такая насыщенная, если взять, к примеру, разработку под тот же iPhone. (Тут могла бы быть развернутая часть о самом ПО, но ввиду некоторых нюансов, таких как незаконченность проекта и отсутствие конкретных результатов, пока ее пропустим).
Оставался последний, и, естественно, самый интересный (логично, не правда ли?) вопрос – денежный, а конкретно – как правильно вывести честно заработанные дензнаки, полученные от продажи ПО на Android Market.

Вдаваться подробности не буду, все-таки статья ориентирована на тех, кто примерно ориентируется в данной теме, скажу коротко — в данном случае под прицелом оказывается сервис обработки онлайновых платежей Google Checkout, который с нерезидентами США изначально не работает. Насколько мне известно, прямых путей решения данной проблемы нет, поэтому пришлось искать обходные дорожки.