Захотелось поделиться с сообществом собственными наблюдениями на тему карьерного роста технаря.

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

Начнем сначала: вы свежий выпускник тех. вуза. Вам 22-23 года, вся жизнь впереди и она прекрасна. В этом прекрасном будущем есть, скорее всего, есть жена-модель, дом – полная чаша, несколько машин, и первый миллион к 30 годам.

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

Вы устраиваетесь на работу, ваше звание — инженер или разработчик. У вас появляются коллеги. Почти все они старше вас. И тут вы, возможно, заметите, что на таком же уровне, как и вы, есть очень пожилые люди. Прямо 30-40 летние мужики, может даже 50ти летние “стариканы”. И многие из них тоже закончили похожие вузы, и многие совсем не дураки, но как-то не сложилось с карьерным ростом…

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

14 сентября прошла третья онлайн-конференция RuHaxe — регулярное мероприятие, посвященное языку Haxe и основанным на нём технологиям и инструментам.

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

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

Введение

По моему скромному мнению, Lisp — жемчужина среди языков функционального программирования. Несмотря на то, что это один из первых в истории (1958 год) высокоуровневых языков, он по сей день не перестает удивлять. Мне кажется, он настолько обогнал свое время, что его час еще только готовится прийти.

Так давайте попытаемся написать программу, которую проблематично будет создать на других языках. Как следует из названия статьи, эта программа будет редактировать собственный код по мере своего выполнения. Для ее создания я использую Common Lisp, а точнее его интерпретатор SBCL.

Нужно ли программисту прикладных приложений понимать как работает БД? Том Кайт, признанный специалист Oracle, автор знаменитой колонки asktom, в своей книге «Oracle для профессионалов. Архитектура и основные особенности.» настаивает, что это просто необходимо. Даже если в вашей команде есть грамотный администратор, знание того, как работает СУБД Oracle поможет вам лучше понимать друг друга и эффективней взаимодействовать, не говоря уже о случае, когда такого специалиста у вас нет. В данном топике я упомяну об основных вещах, понимание которых позволит грамотно работать с БД Oracle и использовать некоторые её особенности с большой отдачей для вашего приложения. Если же вы уже прочитали вышеупомянутую книгу Тома Кайта, то можете просто исползовать эту статью в качестве памятки. Одно замечание — книжку я читал давно, и тогда еще последней версией БД Oracle была 9i, курсы по администрированию я тоже проходил по девятке, так что, если в десятке и выше что-то поменялось и добавилось, то не обессудьте. Хотя я пишу о довольно фундаментальных вещах, которые вряд ли сильно поменяись.

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

• Кто задумывается о производстве электроники? Объясним, почему практически все игроки рынка электроники учитывают в своей работе производственные вопросы: и стартапы, и зрелые компании.
• Из каких этапов состоит процесс коммерческого производства? Разберемся, какой объем работ предстоит в рамках проекта. Кратко и по пунктам.
• Кто участвует в производственных проектах? Перечислим компании, которые нужны для организации производства.

UPD: схема заменена на вариант с контейнерами из С++11, соавторы — в комментариях ниже

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

• рассматриваем «сложный» сценарий компоновки GNU ld;
• учимся использовать прерывания;
• наконец добираемся до hello world!

Предыдущие статьи цикла:

• ARM-ы для самых маленьких
• ARM-ы для самых маленьких: который час?
• ARM-ы для самых маленьких: тонкости компиляции и компоновщик

Примеры кода из статьи: https://github.com/farcaller/arm-demos

Я давно задаю себе вопросы и сам ищу на них ответы: что же есть «идеальная» IT-компания? Для разработчика, для менеджера, для владельца, для клиентов? Что есть «хорошая» IT-компания, что в ней должно быть и чего не должно? В результате для себя я сформировал вот такой вот список, такая квинтэссенция из пожеланий и собственного опыта. Может пригодиться любому разработчику, менеджеру, CEO. Возможно, это и несколько наивно, во многом — более характерно для компаний «не IT», но тем не менее… Принципы «идеальной» IT-компании в моем представлении. Простыми словами и немного по-детски.

Введение

Приветствую вас, хабравчане. В данном топике я хотел бы осветить подробности разработки на C# под разнородные целевые платформы, в первую очередь такие как .NET и браузер (JavaScript). В качестве примера желающие могут изучить веб-сервис по обработке фотографий gfranq.com, в котором реализована клиентская и серверная обработка фотографий с помощью фильтров, а также функциональность коллажей на основе материала, описанного в данной статье.

Так как я не умею подбирать картинки для привлечения внимания, то она будет по теме:

Я давно обещался написать статью о том, как себя показал Haskell в реальных задачах в продакте.

Для тех, кто не уследил — его в начале 2012 пролоббировали и с энтузиазмом начали внедрять программисты в Селектеле. Тогда же я обещал опубликовать отчёт о том, насколько «это всё» можно использовать.

Продакт в коммерческом проекте — это не в маленькая песочница «для себя», не академический эксперимент в области Computer Science. Это бесконечная борьба за «линию партии», когда вокруг ад, ужас и погибель, а оно всё равно должно работать. Int64 в XML-RPC кодируется строкой (потому что int'ы в XML-RPC signed int32), openssl при чтении нескольких сертификатов из файла читает только первый из них, в bool надо писать либо «1», либо «0», но иногда — «2», ибо только так придумали закодировать третий режим — и т.д. и т.п. В этих условиях требования к языку постепенно перерастают в требования к его экосистеме, инфраструктуре, готовности адаптироваться к реальному миру.

Я буду писать о Haskell с позиций product owner'а, менджера проекта, системного администратора, но никак не программиста. Так что не ожидайте от меня задушевных восторгов о том, как изящно через монадки можно сделать семигрупоид и как здорово выводить типы через типы с помощью типов.

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

Начнём с потребительских свойств.

Для современных веб-приложений стало уже нормой использование AJAX при создании пользовательских интерфейсов. Однако, из-за этого, порой, возникают дополнительные сложности. Часто эти сложности связаны с аутентификацией и процессом обработки таких запросов на клиенте.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

Три недели назад мы выступали на коференции RockIT Conf, которая прошла в Таллине в формате баркемпа. На RockIT технические доклады сменялись выступлением рок-команд, в кулуарах царила неформальная атмосфера. Событие прошло в два дня — первый был стопроцентно боевой, на второй народ разошелся и было немного кисло. Организаторы обещали провести следующий ивент в Питере и учесть ошибки первого RockIT.

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

Многое из того, что написано ниже, можно смело вложить в уста Капитана. Да, это действительно так. Но! Я сам из технарей и сам знаю, как часто мы увлекаемся какой-то технической фитюлькой, крутым рефакторингом или внедрением новых технологий. В 90% случаев пользователь об этом не узнает, особенно, если проект новый.

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

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

Рич Хикки произноситит классные, дающие пищу для размышления выступления. Считается, почти всем, если не поголовно, программистам надо их услышать и увидеть. Если вы не интересуетесь Clojure, лучше смотреть с конца.

• Are We There Yet? – 2009 -размышления о том, правилен ли текущий подход к реализации ООП. Обсуждается много вопросов о проектировании Clojure.

Аннотация

В данной статье рассматривается передача данных по шине PCI Express с одновременным участием нескольких ПЛИС. В компьютерной системе, к PCI Express шине которой подключено несколько (в нашем случае 8) оконечных устройств (PCIe endpoints) ПЛИС запускается одновременно несколько транзакций передачи данных двух типов: А) DMA передача между ОЗУ и ПЛИС (чтение/запись) и Б) прямая передача данных между двумя ПЛИС (запись). Используя соединение PCI Express x4 Gen 2.0 при обращении в память была получена скорость записи 1451 МБ/с (90% от максимальной). Скорость записи данных между ПЛИС была равна 1603 МБ/с (99 % от максимальной) при длине пакетов 128 байт и 1740 МБ/с (99% от максимальной) при длине пакета 256 байт. Латентность передачи данных между ПЛИС зависит от количества промежуточных коммутаторов, и была равна 0,7 мкс для одного коммутатора и 1 мкс для трех. Также показано, что при одновременных передачах через общий канал скорость отдельных передач не уменьшается до тех пор, пока суммарная скорость передачи не превышает пропускную способность общего канала; затем канал используется на 100%, а его пропускная способность делится поровну между устройствами.

По мере роста трафика данных между компонентами высоконагруженных систем, все острее встает проблема его точной, а скорее даже точечной доставки. Идеальным решением в данном случае могла бы стать универсальная технология обмена информацией, обладающая высокой пропускной способностью и осуществляющая эффективное взаимодействие как локальных, так и сетевых устройств, то есть по сути объединяющая их в единую матрицу масштаба ЦОД или ядра сети. Забавно, но факт: одна такая «матрица» (а точнее, технология коммутации данных) появилась практически одновременно с фильмом братьев Вачовски. Речь идет о стандарте Infiniband.

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

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

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

А еще говорят, что GC в .NET практически не настраиваемый. А еще, что нельзя посмотреть исходники как классов .NET Framework, так и CLR, GC и т.п.

А я скажу как бы ни так!

В данной статье мы рассмотрим:

• структура организации размещения объектов в памяти
• CLR 4.5 Background Server GC
• правильная настройка сборщика мусора
• эффективный апгрейд приложений до .NET 4.0+
• правильное ручное управление памятью

Вместо предисловия

В ближайшую субботу мы с EvgenyBorisov будем выступать в Питере на JUG.ru. Будет много веселого трэша и интересной инфы (иногда не разберешь, где проходит граница), и одно из моих выступлений будет посвящено WTF-нутости модульной разработки программ. Я расскажу несколько ужастиков, один из которых будет о том, как все пытаются быстро, гибко и корректно описать зависимости в проекте, и что из этого обычно получается. Интересно? Тогда добро пожаловать в ад!


Скорее, конечно, «Хороший, Удобный и WTF-ный».

Никогда не приходил в голову вопрос: "а как сохранить/передать в другой поток ссылку на поле?"? Логичным предположением будет «передам ref в метод и сохраню. Стоп, oh shi~». Да, ref не сохраняются (а ещё, нельзя использовать на них замыкания, так что создать функцию внутри такого метода и создать из её поток тоже не получится). Но зато можно превратить ref в TypedReference с помощью недокументированного ключевого слова __makeref. Увы, TypedReference нельзя напрямую сохранить в поле и не наследует от System.Object, так что каст привычными методами тоже невозможен (да и вообще на их использование наложена целая куча ограничений). Казалось бы, тупик. Но это ещё не всё — есть ещё RuntimeArgumentHandle, который обладает свойствами TypedReference, за одним исключением — после хитрого каста в System.Object его ещё можно использовать до тех пор, пока жив кадр стека, в котором он был создан. Об этом этот пост.