С 5 марта по 10 июня мной был пройден дистанционный курс обучения Массачусетского технологического института по программе 6.002 MITx «Circuits and electronics».



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

Мне вот интересно много ли таких людей как я. Тех, кто за свою бытность в IT-сфере написал множество сайтов, пару-тройку веб-сервисов, несколько интернет-магазинов и, не смотря на все это, понимает, что не является профессиональным программистом, а лишь программистом «так себе». Никто не узнал себя в этом описании? Вот, например, я – такой! Это обо мне!

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

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

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

Бабло
Начну с самого интересного, с денег. Скажем так, под конец моей деятельности (примерно 2010), не особо напрягаясь, работая около двух-трех дней в неделю, можно было смело делать тысяч по 50-70 рублей. Это в Челябинске. Если работать каждый день, то легко было делать от 150 тысяч рублей в месяц и более, но я для этого был слишком ленив. А теперь по порядку.

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

Итак, представьте себе следующую ситуацию. Так уж случилось, что вам надо отрефакторить очень большой кусок кода, целую подсистему. Строк, эдак, на 200К. Причем рефакторинг явно выглядит очень крупным, затрагивающим базовые концепции, по которым построена ваша подсистема. Фактически надо переписать всю архитектуру, сохранив бизнес логику. Такое бывает, если, например, вы сделали один проект и у вас впереди новый, и вы хотите в нём исправить все ошибки прошлого. Допустим, по первым прикидкам, на рефакторинг надо месяца 2, не меньше. В процессе рефакторинга всё должно работать, в том числе нельзя мешать другим программистам добавлять новые фичи и чинить баги в подсистеме. Часто такой рефакторинг бывает насколько сложен, что совершенно невозможно замерджить старый код в новый, а также невозможно выкатить результат по частям. Фактически вам надо заменить двигатель самолёта на лету.

Примеры из практики, как моей, так и моих коллег:

• Переделать всю работу с базой данных с чистого JDBC на Hibernate.
• Переделать архитектуру сервиса с отсылки-приёмки сообщений на удалённый вызов процедур (RPC).
• Полностью переписать подсистему трансляции XML файлов в рантайм объекты.

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

Добрый день всем хаброжителям!

Поводом к написанию статьи послужило, то что к моему большому удивлению на хабре я не нашёл статьи о реализации RESTful Web Service на Java, может, конечно, плохо искал. Да написано про RESTful web services очень много, но как то вот так, чтобы простенько с примерами кода, рабочий сервис, не так уж и легко найти и не только на хабре…

Вообще с REST я познакомился совсем недавно, не больше месяца назад. Так что буду очень благодарен за советы, поправки и критику!

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

По моему первому впечатлению: действительно вещь очень удобная, а главное очень простая, ещё и если использовать JSON, а не XML, ну по крайней мере мне так показалось после опыта работы с SOAP и WSDL. Ну, да об этом я думаю и так все знают, кто хоть немного работал с веб сервисами.

Так что, кто заинтересовался реализацией, прошу под кат

От переводчика

Недавно на хабре появились первая и вторая части истории о создании Warcraft: Orcs & Humans, написанные Патриком Вайатом. Блог Патрика содержит не только воспоминания о былых днях, и сейчас вашему вниманию предлагается его статься о том, что нужно делать, чтобы всегда иметь возможность найти работу в сфере разработки ПО. Хоть Патрик говорит о рынке США, практически все применимо и к нашим современным реалиям.

Недавно я имел удовольствие побывать на заводе по производству Arduino.



Arduino производится в Скарманьо, маленьком городе недалеко от заводов Olivetti на окраине Турин в Италии.
Вся забота по производству печатных плат, установке компонентов и распространения лежит на плечах этого городка. Я был в восторге от увиденного и хотел бы поделиться некоторыми фотографиями.
Изюминкой моей поездки был System Elettronica, завод по производству печатных плат для Arduino.

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

Моя профессиональная карьера сложилась таким образом, что в настоящий момент я работаю техническим директором в компании Knoema и в моем подчинении оказалась очень необычная команда состоящая из российских (Пермь) и индийских (Bangalore) разработчиков. За почти 2 года такой работы накопилось много полезных наблюдений. Да и вообще тема достаточно интересная поскольку практически все мои знакомые из ИТ интересуются как оно там в Индии и чем русские разработчики отличаются от индийских. До этого я более 10 лет работал в разработке ПО в России и США, из них более 7 лет руководителем разных рангов. Вот я и решил поделиться накопившимся «интернациональным» опытом.

Как обычно строят процесс тестирования непросветлённые тест-менеджеры?

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

Релиз.

Не работает основной функционал.

Почему такое возможно?

1. Заведение всех подряд ошибок мешает разработке. Разработчики тратят своё время на исправление минорных ошибок и вносят новые, зачастую более серьёзные.

2. Потраченное на мелочи время не дало возможности проверить более серьёзные пользовательские сценарии и найти более критичные дефекты.

3. Обратная связь по статусу сборки предоставлялась разработчикам с запозданием: вместо критичных дефектов непрерывно сыпались миноры.

4. Проектный паттерн «дохлая рыба» сыграл своё дело: все участники команды прекрасно понимали, что протестировать всё нельзя, и это не могло не сказаться на качестве работы. А реалистичных целей им никто не поставил…

Что просветлённые тест-менеджеры делают по-другому?

Что они поменяют в первую очередь?

Для бизнесменов есть разные книги: «Как сделать ЭТО», «Как сделать ТО». А есть книги, задача которых — мотивировать, помочь посмотреть на ситуацию с новой стороны, побороть страхи и начать действовать.

Именно к ним я обращаюсь в те моменты, когда что-то не прёт, наваливает усталость, и не совсем понятно зачем всё это. Ниже — моя любимая выборка из 3ёх книг, которые могут помочь любому бизнесмену и которые сделают бизнесмена даже НЕ из бизнесмена :)

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

Для этого я рассмотрю, как понять, чему вообще учиться, и как найти наиболее эффективные и подходящие способы обучения?

В октябре я уже рассказывала о способах оценки тестирования, все страждующие и сочувствующие могут посмотреть запись здесь. А сегодня мне захотелось затронуть тему метрик проекта в целом, причём метрик не «длягалочных», а метрик «пользуприносящих» и «проектыулучшающих». Именно поэтому, вместо сухих формул и перечня метрик, я расскажу 3 истории из опыта о внедрении и использовании строго определённых метрик в строго определённых условиях — и о результатах, которые с их помощью удалось достичь.

Зачем что-либо измерять?

Есть проект. Ваш любимый, родной, которому вы желаете расти и процветать.
Но как вы оцените его процветание, если нет критериев этого самого процветания?
Как вы сможете оперативно среагировать на проблемы до того, как они стали неисправимыми, если не будете использовать «датчик грядущей Ж»?
Как вы поймёте, что именно следует улучшать, если вам неизвестен источник проблем?

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

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

А если не приходят, значит метрику можно смело выбросить ;)

Время от времени в прессе всплывают всевозможные интересные факты про деятельность различных компаний. К примеру, на Хабре приводили показания Айва Джонатана, касательно дизайна ранних версий яблочных продуктов. Я решил, что было бы интересно рассказать, что это за показания, почему их приходится давать, как устроен процесс и в каком случае вам, возможно, придется пройти через это непростое испытание.

Материал этой статьи написан на основе собственного опыта. Если ваша деятельность как-то связана с американским рынком, то рано или поздно и вам (или вашим коллегам) предстоит получить этот опыт, но об этом поговорим в конце статьи.

Сегодня в зарубежных блогах появилась занятная новость о необычном поведении браузеров: на днях Chris Coyier, автор сайта css-tricks.com показал, как классу можно дать больший приоритет, чем id. Нужно всего лишь применить к объекту 256 классов!

С 2007 года я работаю над созданием странного девайса — носимого компьютера (wearable computer). Поначалу казалось, ничего сложного: ноутбук в рюкзак, дисплей-очки на нос — и вот у тебя какой-никакой, а вполне носимый компьютер, позволяющий развлекаться с дополненной реальностью и прочими любопытными фичами. Главное подобрать подходящее железо — и в путь! Но все оказалось не так-то просто.

Картинки есть (и много), но они долго грузятся (хабра-эффект?) перезаливаю их на habrastorage.org…

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

Все советы автономны и их порядок не имеет значения.

На сайте Groklaw публикуется текстовая трансляция судебных слушаний Oracle против Google, где речь идёт о возмещении ущерба $150 тыс. за «воровство» для Android функции rangeCheck и тестовых файлов. В обсуждении встречаются интересные моменты. Например, вчера судья Алсуп, ведущий это дело, вступил в небольшую перепалку с адвокатом Дэвидом Бойзом, который представляет интересы Oracle: см. запись разговора.

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

Кроме того, для меня не ясно, что справедливо сравнение девяти строк кода и 15 миллионов, потому что из них 10 миллионов составляет ядро Linux. Но всё равно, девять строк — это небольшой процент. Тестовые файлы гораздо больше, но они не присутствуют, по крайней мере, в текущей версии Android.

Данная статья является кратким конспектом по книге "Andre Kukla: Mental Traps"

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

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

Наверняка многие слышали про так называемые «бандлы» — мероприятия, организаторы которых собирают несколько различных игр в один пак и продают по системе Pay What You Want. Вырученные в итоге деньги делятся между разработчиками, организаторами и благотворительными компаниями. Наиболее ярким представителем компании-организатора бандлов является Wolfire Games с их популярнейшим Humble Indie Bundle. Кроме того, существуют такие бандлеры как Indie Royale и Indie Gala. Своим опытом в сотрудничестве с Indie Gala я и хотел бы с вами поделиться.

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