Вступление переводчика

Занимаясь разработкой для платформы Windows Mobile в течение последних двух лет, я не мог не слышать о новых платформах, таких как Apple IPhone, Google Android, Palm Pre. Какое-то время назад я натолкнулся на блог разработчика Windows Mobile, который вел свой блог в достаточно издевательском стиле, пародируя «30 days of Windows Mobile», его посты из той серии назывались «30 Days of Bitching about .NET CF», что переводится как «30 дней сплетен за спиной у .NET CF». В этих постах он описывал подводные камни, с которыми сталкивался при разработке.

Несколько месяцев назад этот блоггер приобрёл HTC G1 и погрузился в мир Android девелопмента. Выпустив пару приложений на Android Market, Кушик Дутта (а именно так его зовут) решил написать сравнительный анализ опыта разработки для Windows Mobile vs Android.

Спасибо небу за то, что в субботу шел дождь, и я это прочитал (а вы скажите спасибо за то, что перевел). В воскресенье, однако, светило солнце и форматирование текста было отложено.

Отдельное спасибо автору, за разрешение отдельной публикации.

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

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

И так узкое место при запуске это загрузка .sqlite, базы данных вашего профиля. При интенсивной работе с Фоксом, базы разрастаются, в них появляются «пустые места», ну и главный недостаток, файл базы данных становится сильно фрагментированными. Для решения подобной проблемы существует специальная команда «очистки», точнее операция пересоздаёт файл базы, но уже без пустых мест. Для этого нужно проделать следующее:

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

Software Transactional Memory (STM) — это альтернатива блокировкам и другим традиционным механизмам синхронизации асинхронных операций и потоков при доступе к общему участку памяти. Механизм STM похож на работу транзакций в современных СУБД и, хотя его использование в общем случае медленнее использования механизма блокировок, STM предлагает разработчику более простой способ управления параллельными вычислениями.

Использование STM в .NET крайне просто:

Atomic.Do(()=> {
<statememts>
});

где statements — это выражение которое должно выполняться в транзакции.

Существует масса библиотек реализующих STM для множества языков. STM для .NET ранее существовала в виде отдельного проекта группы Microsoft Research, кроме того для C# существовует еще 4 библиотеки STM. И вот теперь, этот механизм стал частью фреймворка.

* скачать .NET 4.0 с STM msdn.microsoft.com/en-us/devlabs/ee334183.aspx
* wiki-статья про STM en.wikipedia.org/wiki/Software_transactional_memory (eng)
* статья Beautiful Сoncurency (Haskell) research.microsoft.com/en-us/um/people/simonpj/papers/stm/beautiful.pdf (pdf), спасибо shai_xylyd

via www.infoq.com/news/2009/07/Software-Transactional-Memory

Метапрограммирование в языке io

В продолжении серии статей про чудесный язык io я таки собрался написать про метапрограммирование.
habrahabr.ru/blogs/crazydev/29375
habrahabr.ru/blogs/crazydev/28254
habrahabr.ru/blogs/crazydev/28167
habrahabr.ru/blogs/crazydev/28041

Метапрограммирование — создание программ, которые создают другие программы как результат своей работы (либо — частный случай — изменяющие или дополняющие себя во время выполнения).
© Православная википедия

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

Если посмотреть на крестных отцов io, то можно увидеть Lisp, Smalltalk, Self и другие динамические языки. Но все они решают проблему метапрограммирования по своему, например Lisp генерирует код в процессе компиляции из макросов, очень мощных штук. Smalltalk содержит развитую систему «отражений» (reflection) позволяющую гулять по дереву объектов в любую сторону. Io пошел по пути smalltalk'а и строит свои динамические механизмы на базе объектной модели, а не универсальности синтаксиса (как лисп).

По факту защиты мной диплома образовалось некоторое свободное время и я таки решил собраться и написать про эту чудесную штучку.
Мы в последнее время видим всплеск интереса ко всяким языкам очень высокого уровня, с анонимными функциями, каррингом, мапом/фолдом, метапрограммированием и прочим блэкджэком. Слава богу, я считаю.
Задачи усложняются и если люди применяют относительно низкоуровневые средства разработки зачастую наступает ситуация, когда набор абстракций оказывается мал в рамках решаемой задачи, примерно так появляется «спагетти» и велосипеды. Хорошего мало. Хотя умалять роль низкоуровневого программирования не хочется совершенно, по понятным причинам.

Совсем недавно, в 2002 году, бравый американец Стив Декорте понял, что ему как-то все вокруг не нравится. Ну то есть нравится, но как-то по частям. Нравится Smalltalk своей Ъ-ООП природой, нравится Lisp своей системой метапрограммирования и общей мегаизвратностью, нравится Self своими прототипами, нравится Lua, потому что маленькая и клево встраивается куда угодно. А вот что бы все и сразу — что-то не то. Погоревал бравый американец, да и наколбасил свой собственный язык программирования — Io.

Io

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

Ну что, поехали.

В продолжение серии статей про Io, хотелось бы отдельно остановиться на синтаксисе языка.
В двух словах синтаксис Io можно описать так: простой, но странный. Многих удивит такой подход, но, спешу заверить, как и в Lisp, синтаксис неудобен только при взгляде со стороны. С эстетической точки зрения можно отдельно выделить тот факт, что многие прогаммы на Io внешне кажутся излишне разреженными, на экране остается много «лишнего», незаполненного полезным кодом места, это ощущение меня не покидает довольно давно, я пока не придумал, как полностью избавиться от этого вывиха мозга, я просто придумал для себя некоторые правила оформления кода, при соблюдении которых эффект значительно сморщивается:

• Длина строки не должна превышать 80 символов (Привет, text mode!)
• Между клонированием объекта и описанием тела нового должна быть пустая строка
• Методы и свойства группируются
• Без лишней необходимости скобки на новую строку не переносятся

Ну что, поехали. Вынос мозга №2.

Введение

Продолжая писать про io, совершенно необходимо остановиться отдельно на устройстве объектной системы этого чудесатого езычка. Главная проблема в том, что даже если вы «знаете» ООП, вполне может сложиться ситуация, что вы просто не поймете, как оно устроено в io. Сейчас под ООП почему-то подразумевается модель Java, чаще всего. C++ нельзя назвать объектно-ориентированным языком, потому что он язык поддерживающий парадигму ООП, но это не его основная парадигма. Java больше подходит под гордое звание Ъ-ООП языка, но вот беда, ООП диктуемое Java-like языками довольно извращено. Изначально принципы ООП зарождались в Smalltalk'е и там все выглядело несколько иначе, объекты общались друг с другом не посредством вызова методов, а посредством передачи друг другу сообщений, мне до сих пор странно, почему же от этой модели ушли, ведь такое построение позволяет ввести прозрачную параллельность в язык без костылей. Посмотрите на нынешние круто параллелящиеся языки, тот же Erlang например, там все сделано через сообщения. Опять же нагородили огородов из RPC, COM и прочего dbus'а. А ведь как все хорошо начиналось.

Я часто общаюсь с людьми на тему гибких методов разработки ПО, иногда пишу статьи про это (например, недавняя статья на хабре про Канбан в IT).
И я могу сказать, что основной аргумент, который люди приводят против этих методов, который останавливает многих даже от мыслей про Канбан, Scrum или XP — это якобы низкий уровень контроля за разработкой у этих методологий.
При этом некоторые воспринимают, как непрофессионализм, доводы о том, что уровень контроля не сильно-то зависит от методологии, да и вообще контроль в сфере разработки ПО — это по большому счету фикция.

Для таких людей я перевёл новую статью Тома Демарко, одного из основоположников инжиниринга ПО, разработчика метрик для ПО и соавтора известной книги «Человеческий фактор: успешные проекты и команды».
Эта статья сильно провокационная и сейчас широко обсуждается в англоязычных блогах и странно, что я еще не встречал ее переводов на русский. Но, несмотря на провокационность, в ней есть несколько очень правильных идей, которые могут изменить у кого-то представление о важности и возможности контроля за разработкой.
В общем, читайте перевод статьи под катом.

В этой статье я расскажу с чего начинался мой бизнес и чем является сейчас. Сейчас это интернет-компания в Нижнем Новгороде.

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

Не простое это дело — собственный бизнес :)

Что может быть лучше, чем описание девяти классных фишек App Engine? Разумеется, описание десяти. Участвуя в обсуждениях в группах, мы заметили, что некоторые возможности App Engine часто остаются незамеченными, так что мы выбрали чуть меньше, чем одиннадцать интересных фактов, которые, возможно, просто позволят вам писать программы по другому. Но довольно слов, смотрим первую фишку:

Мы с участниками социальной сети open-life.org решили сделать перевод статьи Джо Шилдза (Jo Shields) «Here we go again – why Mono doesn’t suck». В результате получилась статья «Почему Mono хорош». Копию данного перевода можно прочитать здесь: Почему Mono хорош — open-life.org

Прим.: Если кто захочет инвайт на open-life.org — стучитесь в личку

Я участник Debian Mono Group, Debian CLI Applications Team, и Debian CLI Libraries Team. И уже в течении года работаю над сопровождением пакетов проекта Mono и программ, которые используют его в ОС Ubuntu (и Debian). Мне хорошо известны горячие споры, угрозы и последующие переходы на личности, и сейчас я принимаю ваш «вызов». В этой статье я говорю от себя лично — не от проекта Debian, не от Ubuntu, не от Mono, и не потому, что меня попросил мой начальник.

Вам хотелось «объективного пояснения, чем хорош Mono, почему он не представляет угрозы и почему его следует включить в Ubuntu по умолчанию»? — Я отвечу на эти 3 вопроса по очереди, затем предложу общий вывод к этой статье, а так же к более широкому движению «Анти-Mono». Это сообщение подписано GPG (прим. переводчика: GPG=GNU Privacy Guard — свободная альтернатива набору криптографического ПО PGP) для подтверждения факта его публикации без изменений. Оригинальный текст доступен по адресу retro.apebox.org/herewegoagain.txt чтобы каждый желающий мог проверить его подлинность самостоятельно.

Привет, хабрачеловек. Сегодня я расскажу тебе про некоторые фундаментальные вещи в computer science: частичные вычисления, три проекции Футамуры и суперкомпиляцию.
 
 

1. Сразу к коду

-- функция, которая возводит x в степень y (неотрицательную)
power x y =
    case y of
        0 → 1
        1 → x
        _ → x * (power x (y - 1))


Довольно много написано о мотивации программистов, и как-то маловато информации о мотивации менеджеров. Итак, тезис: в IT-аутсорсе отсутствует мотивация менеджеров проектов. Вообще.

UPD: Перенес в Менеджмент проектов. Спасибо за карму!

Cocotron — это реализация runtime для Objective-C, похожего на рантайм Apple — Cocoa. Он достаточно сильно отличается от другого популярного открытого рантайма — GNUstep, как в целях, так и в реализации.

Cocotron отлично подходит для портирования кода с платформы OSX на Win32. Конечно реализация API далека до идеала, но, как показывает практика, разработчики всегда быстро решают проблемы.

Изначально Cocotron использовался только при кросс-сборке на базе XCode и mingw-toolchain. При кросс-сборке доступно развертывание на Windows, Linux и Solaris.

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

1 Введение

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

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

Намедни возникла задача внедрения PayPal на коммерческий сайт, работающий под ASP.NET. После детального изучения данного вопроса, выяснилось, что в рунете инфы по нему очень мало. Посему думаю, что будет уместно осветить данный вопрос. Начнем, как всегда, с постановки задачи.

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

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

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