После выпуска 2000 иконок FatCow прошло более года. Пошел четвертый год рисования. Страницу посетило 560,096 (288,511+235,221+36,364) посетителей. Чтобы дойти до 3500 иконок, работы хватит до февраля 2013 года. Если добавить размер 64x64, то до середины 2015-го года. Пока вложено $76778 и 2000 часов работы. Тут выложили 3000 иконок, за неделю до выпуска на официальном сайте, ибо владельцы коровы (Bluehost) заняты покупкой крокодила (HostGator).



Чтобы понять, какой набор иконок самый уникальный в мире, пришлось рассортировать 7422 иконок. Результат не подвел…

Всем iOS (да и MAC OS X) разработчикам известен такой системный фреймворк как Core Data. Эта штуковина представляет собой достаточно мощную ORM (по крайней мере для мобильной платформы).

Изначально в нашем приложении использовалась одна база данных для всей информации, которую нужно было сохранять в приложении. Но по мере разбухания функциональности стало понятно, что некоторые сущности логичнее расположить в разных базах, или даже в разных типах хранилищ (persistent store). Не буду углубляться в подробности, главное — что изначально монолитное NSSQLiteStore нужно было разделить на несколько.

Первая часть про различные уровни сложности школьных задач.
Вторая часть про типы видео-лекций.

В этой части я хочу обсудить технологии школьного интернет-образования. Под школьным образованием я подразумеваю такое, при котором за успеваемостью ученика необходимо как-то следить. В качестве примеров будут рассмотрены:
● khanacademy.org Гигант в этой отрасли.
● eftsh.ru Электронная ФТШ, проект при МФТИ.
● 100ege.ru Портал по подготовке к вузовским олимпиадам, ЕГЭ и ГИА.
● interneturok.ru и univertv.ru являются архивами лекции, но на данный момент отсутствует функционал взаимодействия с учеником.
● dnevnik.ru Всероссийская бесплатная школьная образовательная сеть.

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

Итак, обладая 10 летним опытом работы в IT, и пройдя множество ролей: тестировщик, дизайнер, программист, ведущий программист, руководитель: группы, отдела, подразделения, департамента интернет проектов, директора по развитию и наконец директора.

Я не претендую на авторство — скорее это народное творчество: «слова народные, музыка народная, исполняет — автор».

Поехали!

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

В данной статье речь пойдет о приложениях с открытым кодом, которые размещены в App Store. Мы будем рассматривать только приложения которые одобрены компанией Apple и опубликованы. Начинающие разработчики могут изучать их код для повышения своих навыков.

В топике блиц-обзор книг, которые будут полезны IT-специалистам, бизнесменам и тем, кто собирается открыть своё дело. Рядом с каждой — короткие пояснения, почему и зачем стоит прочесть.

Отобраны лучшие 10% из примерно 200 прочитанных книг о маркетинге, продажах и всем связанном — самые «пробивные» вещи, которые помогут вам не тратить время на всякий шлак, а сразу начать с главного.

В конце — суммация книг, которые хабровчане рекомендуют в комментариях помимо основного списка.

Сегодня мы поговорим о распределенных, гетерогенных и местами довольно серьезно и разнообразно нагруженных интернет приложениях на примере портала http://www.abbyyonline.com. Я постараюсь не углубляться в технические подробности, имеющие отношение к конкретной платформе, и, хотя основная часть описанного приложения реализована на ASP.Net MVC, возможно, данный материал заинтересует всех, имеющих отношение к веб-разработке, вне зависимости от используемого инструментария.

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

Скажу сразу — «Америку не открываю», так же как не «изобретаю велосипед». Статья базируется на модели ситуационного лидерства Херси-Бланчарда. Сама модель в значительной степени изменена в применении к управлению именно ИТ-командами в нашей стране и подкреплена практическим опытом управления командами в Майкрософт Рус и в собственном бизнесе.

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