Тема DI/IoC достаточно простая, но в сети очень сложно найти хорошее описание того, как это работает и зачем это нужно. Вот моя попытка, с использованием Unity. Хорошо ли объяснена тема – судить вам.

Год назад мы с командой решили перейти с SVN на Git. Зачем это было надо — писать не буду, т.к. на эту тему уже и так много написано. А хочу я описать типичные алгоритмы работы, понятные человеку, который долгое время пользовался SVN. Ниже — памятка, написанная для команды год назад, чтобы легче было мигрировать. Надеюсь, кому-нибудь пригодится.

Обсуждая с различными людьми — в большинстве своём опытными разработчиками — классический труд «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» Гаммы, Хелма и др., я с изумлением встретил полное непонимание одного из базовых подходов ООП — различия классов и интерфейсов.

Списки книг

• 25 бесплатных книг по информатике
• Шпаргалки
• CodePlex: Список бесплатных книг
• Бесплатные технические книги
• Galileo Computing (Немецкий)
• How to Design Programs: An Introduction to Computing and Programming
• Microsoft Press: Бесплатные книги
• MindView Inc
• Проект O'Reilly's Open Books
• TechBooksForFree.com
• Theassayer.org
• Wikibooks: Программирование
• Неплохая подборка, редактируемая сообществом (JIghtuse)
• Книги на Русском (telteron)

Программирование графики

Хабралюди, добрый день!
Сегодня хочу начать написание ряда лекций с практическими заданиями по книги Михаеля Привата и Роберта Варнера «Pro Core Data for iOS», которую можете купить по этой ссылке. Каждая глава будет содержать теоретическую и практическую часть.



Содержание:

• Глава №1. Приступаем (Практическая часть)
• Глава №2. Усваиваем Core Data
• Глава №3. Хранение данных: SQLite и другие варианты
• Глава №4. Создание модели данных
• Глава №5. Работаем с объектами данных
• Глава №6. Обработка результатирующих множеств
• Глава №7. Настройка производительности и используемой памяти
• Глава №8. Управление версиями и миграции
• Глава №9. Управление таблицами с использованием NSFetchedResultsController
• Глава №10. Использование Core Data в продвинутых приложениях

Почему эта книга заслуживает перевода

Хочу поделиться своим мнением с хабрасообществом о книге «Passionate Programmer», перевод одной из глав которой представлен ниже. Книга вышла в 2009 году, но среди российских программистов она не очень широко известна, тем не менее многие, кто познакомился с ней, считают её очень достойной. Чад Фаулер (автор книги) выложился очень хорошо, чтобы передать читателям свой богатый опыт (на данный момент он CTO 6Wunderkinder, имеет более 20 лет стажа разработки и в виду своего большого опыта и круга интересов он желанный гость на Ruby- и IT-конференциях). Да, уже и не помню как нашёл эту книжку, но помню, что именно предисловие от Кента Бека (идейный вдохновитель Test Driven Development и Extreme Programming) послужило причиной прочитать её.

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

После прочтения книги я заинтересовался Чадом. Нашёл его блог в сети. Как оказалось, он начал выкладывать в нём главы из своей книги (на данный момент опубликовано 2 главы из 53). Я спросил разрешения на перевод для хабра, он ответил, что это хорошая идея, но только сначала мне надо отправить ему письмо с тем, что конкретно я хочу переводить (видимо это пожелание было как-то связано с тем издательством, где была опубликована книга). После моего ответа неделю было молчание, я отправил повторное письмо — ответа снова не было. Потом я получил от него приглашение на Wunderlist (сервис, за который он отвечает на данный момент). В общем, я посчитал, что если явного запрета не было, а эти главы уже и так находятся в свободном доступе, и он ещё не совсем про меня забыл, то делать перевод можно. В общем, если перевод сообществу окажется полезным, я продолжу переводить другие главы. В тексте возможны ошибки (делал вычитку несколько раз, но всё же вдруг), поэтому заранее прошу прощения и прошу сообщать мне обо всех проблемах через личные сообщения.

Миф 1. Университет не должен давать профессию — университет должен учить студента учиться.

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

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

И вот на пятом курсе подходит очередной выпускник к лектору и говорит:
— Профессор, я иду на красный диплом, но не могу найти работу.
— Задача университета — научить человека учится.
— ??

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

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

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

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

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

Среда разработки и инфраструктура

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

Для разработки плагинов подойдет любая современная версия Intellij IDEA – она уже включает в себя полный набор необходимого инструментария.

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

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

Большая часть расписаний, с которыми вы встретитесь, будет представлять из себя бездушные отписки. Совершенно забытые, они хранятся в каком-нибудь общем каталоге. После выпуска продукта с опозданием на пару лет странный парень, в чьем офисе, говорят, видели картотеку, принесет на обсуждение причин провала старую распечатку, которую все засмеют. «Только гляньте! Мы запланировали две недели, на переписывание системы с нуля на Ruby!»

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

Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

Поводом, для написания данного поста, послужил выход новой версии UI фреймворка Feathers.

Являясь AS3 разработчиком, я слежу за развитием данного продукта начиная с ранних бета версий. На данном этапе развития этого продукта, можно с увереностью утверждать, что он готов к массовому использованию. А не только в кругу комьюнити и Flash энтузиастов.

Feathers это библиотека компонентов пользовательского интерфейса использующая все возможности GPU ускорения через Starling фреймворк. Библиотека содержащая в себе быстрые, легковесные и легко расширяемые UI контроллы для мобильных и десктопных приложений.

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

Но, увы, всё это великолепие разбивается о суровую действительность и реальные проекты. Если мы говорим о продакшн-проекте, то пользователей не волнует, насколько красив ваш код и насколько хороша архитектура, их волнует, чтобы проект хорошо работал. Но я всё равно считаю, что в любом случае нужно стремиться писать правильно, просто при этом фанатизма быть не должно. После чтения различных холиваров на тему правильных подходов к написанию кода мне в глаза бросилась одна тенденция: каждый пытается применить означенные подходы не в целом к программированию, а только к своему опыту разработки, к своим проектам. Многие не осознают, что хорошие практики — это не абсолютные правила, которые должны строго соблюдаться в 100% сценариев, это лишь советы о том, как следовало бы поступать в большинстве ситуаций. На каждую хорошую практику всегда можно придумать несколько дюжин примеров, в которых она работать не будет. Но это вовсе не означает, что хорошая практика не такая уж и хорошая, просто её применили не к месту.

Здравствуй, Хабр!



Осенью прошлого года я открыл Хекслет – образовательный проект с бесплатными онлайн-курсами по программированию на русском языке. Спустя неделю стартовал первый курс – Разработка под OS X. Это был очень интересный опыт, но было допущено много ошибок в разработке этого проекта.

Сегодня я рад объявить о перезапуске Хекслета! Что вас ожидает:

• Новый сайт и удобный, быстрый движок. Со старым было столько проблем, что многие студенты просто не могли им нормально пользоваться.
• Улучшенный формат курсов. В первой версии я пытался эмулировать физический университет в интернете, а нужно было делать изначально онлайн–курс.
• Личное общение с преподавателем. Эту особенность хочется сделать важным отличием от други образовательных проектов.
• Новые, интересные курсы и планы на будущие курсы.

Уже сейчас можно записаться на три первых курса:

1. Разработка приложений на Java
2. Структура и интерпретация компьютерных программ (SICP)
3. Разработка под OS X

Трейлер очень интересного курса SICP:



Под катом – описания текущих и будущих курсов.

Здравствуйте, дорогие читатели Хабра!

Уже довольно давно работаю фрилансером и иногда беру пару-тройку простеньких проектов за $100-200 для разгрузки мозга. В этот раз клиент попросил использовать внешние кнопки регулировки громкости в iPhone. Проблема состояла в том, что встроенного API для внешних кнопок в iOS не существует: до недавних пор использование хардверных элементов устройства, отличное от системного поведения, было запрещено. Поэтому различные приложения типа «Camera+» и «Camera Pro» никак не могли донести подобный функционал до пользователя. Однако, по счастливой случайности, в iOS 5 разработчики Apple сами начали использовать подобный подход к интерфейсу: сделать фотографию в системном приложении камеры теперь можно, нажав на клавишу увеличения громкости.

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

На фоне обсуждений новой, отлично оптимизированной OS X Mavericks, и сомнительно переработанного интерфейса iOS 7 с его убогими иконками приложений, представленных вчера на WWDC, совсем незаметной прошла еще одна новость — one more thing , о которой не сказали на презентации. О ней зарегистрированные разработчики узнали в письме новостной рассылки iTunes Connect:

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

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

Но сначала история…

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

Таким образом, как и должно было произойти, у меня появился свой собственный проект. Менеджер по работе с крупными клиентами объяснил мне в общих чертах, чего хочет клиент, мы это обсудили, и я сказал: «На эту работу уйдет 3 недели.» «Хорошо», — ответил он. И так я приступил к программированию.

Как вы думаете, сколько времени у меня ушло на этот проект? Четыре недели? Может быть пять?

Мм, вообще-то: три месяца.

У меня остались четкие воспоминания о том времени – мое представление о себе было тесно связано с ощущением, что я — «хороший программист», в чем я сильно разочаровался. Я потерял сон, у меня случались небольшие приступы паники. И этому Не Было Конца. Я помню, что у меня сосало под ложечкой при разговоре с тем менеджером, я снова и снова объяснял, что у меня до сих пор нет ничего, что можно ему показать.

В один из таких черных периодов я решил, что Больше Никогда Не Буду Совершать Подобных Ошибок.

К сожалению, в ходе своей карьеры, я уяснил нечто очень тяжелое: я постоянно совершаю подобные ошибки.

В этой статье я попытаюсь поделиться своим опытом в проектировании пользовательской бизнес-логики. Это явно не претендует на полноценный ликбез, т.к. я всего лишь вспоминаю то, через что прошёл лично я, какие ошибки я допустил, и как мне их удалось (или не удалось) исправить в будущем. Наверняка, опытные системные архитекторы уже все проходили и знают, однако надеюсь, что некоторые советы таки будут полезны.
Мы использовали (и используем) клиентскую часть на WPF/Silverlight, WCF сервисы и СУБД Oracle, Postrges, MsSQL. Код написан по MVVM, использована Prism для модульности и навигации. Не могу точно сказать, какие из тезисов подойдут для других платформ и языков.

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

Итак, поехали.

BADLAND был запущен 4 апреля 2013 на App Store для iPad, iPhone и iPod touch. С тех пор было продано более 100 000 экземпляров. Сыграйте в эту игру (iTunes link) или посмотрите трейлер, прежде чем продолжить чтение — так вы получите более полную картину об игре, про которую я собираюсь рассказать. BADLAND была создана нашей инди-компанией, называемой Frogmind и состоящей из двух человек. Это наша первая игра на iOS и в ней используется последняя версия cocos2d-iphone 2.1 наряду со множеством других open source библиотек.