В последнее время на Хабре зачастило упоминание о Nemerle. Хотите узнать, что это такое и как его едят, а вернее — как с его помощью едят (задачки)?

Попробую показать на простом примере, но для этого вам придется

Решил поделиться опытом создания и продвижения компьютерной фирмы. Думаю, кое-кому да и пригодиться. Тем более, что старт был с абсолютного Кельвиновского нуля. А чего мы и как добились, можно увидеть под катом.

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

В сообществе сторонников Open Source-смартфонов проекта Openmoko уже давно повисли довольно унылые настроения. И причин тому — масса. Но вот, похоже, и подоспела «последняя капля».

Steve Mosher из Openmoko Inc. в почтовой рассылке заявил, что работы над созданием GTA03 (это кодовое название следующего смартфона от Openmoko) больше не ведутся.

Причины банальны: не хватает ресурсов. Вообще говоря, практика показала, что их не хватает даже для того, чтобы довести до ума FreeRunner. Одним лишь сообществом Open Source-энтузиастов «отделаться» не удалось.

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

P.S. Немного подробностей о роковом письме Mosher'а на русском языке опубликовал на linuxphone.ru.

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

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

(Фото предоставлено digi.no)

Как известно, Opera Mini позволяет экономить время и трафик (а, следовательно, и деньги) за счёт того, что все данные перед отправкой на мобильные телефоны обрабатываются на специальных серверах компании Opera Software. Наиболее мощная серверная ферма Opera Mini находится в Норвегии и является самой большой в стране. Каждую секунду серверы обрабатывают тысячи запросов с пользовательских телефонов на просмотр той или иной страницы. Объём данных проходит огромный, но его масштабы по цифрам как-то слабо представляются, если честно. К примеру, за ноябрь прошлого года серверы Opera Mini отправили пользователям 82,9 ТБ данных, обработав при этом более 800 ТБ реального контента. Вот как понять, много это или мало? Даже если привести для сравнения данные по всему интернету, всё равно все эти тера- и петабайты останутся лишь цифрами. Впрочем, у самих разработчиков есть способ визуально оценить активность пользователей Opera Mini. Сами авторы популярного браузера называют своё «всевидящее око» по-простому — Opera Mini глобус.

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

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

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

Начал я обустраиваться под Linux'ом и обнаружил, что мне сильно не хватает тех красивых попапов, уведомляющих о приходе новой почты, которые умеет показывать Google Talk под Windows. Гугление обнаружило несколько готовых скриптов, позволяющих реализовать подобные попапы (среди прочих: bash-скрипт, bash-скрипт + python-скрипт, плюс pidgin умеет проверять почту), но все подходы слегка уродливы были мне не по душе и требовали доработки напильником, поэтому я решил сделать всё с нуля (пусть будет уродливое, но своё!). О вещах, с которыми я столкнулся в процессе и пойдёт речь…

Продолжая статьи о Git, распределенной системе контроля версий, с помощью которой ведется разработка таких проектов как Linux и Ruby on Rails, хотелось бы сказать и несколько слов о работе с ним под Windows.

Официального порта Git под Windows нет, есть mingw+msys порт по адресу code.google.com/p/msysgit/downloads/list

Как-то понадобилось написать проект на ruby под Windows — возникла проблема с виндовым переносом строки, который вставлялся во все файлы автоматически, вследствие чего проект не работал вообще. Оказалось, что для исправления нужно подправить gitconfig, в котором разработчики msysgit предусмотрительно вставили автопостановку CRLF.

Отключается она элементарной правкой gitconfig (можно найти в папке C:\Program Files\Git\etc), меняем содержимое секции core на следующее:

[core]
autocrlf = false
symlinks = false

Надеюсь, совет окажется многим полезным :)

Mercurial (он же Hg) — весьма приятная распределенная система контроля версий (distributed VCS). Среди удобств DVCS вообще и Hg в частности можно особо выделить высокую гибкость. Репозиторий может называться как угодно, копироваться куда угодно, коммититься в продакшн по произвольным цепочкам (скажем, через QA или напрямую) и так далее.

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

Если два репозитория вложить один в другой, Mercurial будет рассматривать их изолированно. Команды, адресуемые внешнему репозиторию, не распространяются на вложенный. Но как же управляться с проектом, если он раздроблен на изолированные фрагменты — этакие пузырьки, один в другом? Или, другими словами, как нам за деревьями (репозиториями) увидеть лес (проект) и работать на его уровне? От мучений нас избавит ForestExtension — расширение для Mercurial. Этот Forest добавляет несколько команд, идентичных базовым, но учитывающих вложенность репозиториев.

Некоторое время назад я, разбираясь с различными системами контроля версий, наткнулся на видео битвы трех гигантов — Git, Mercurial и Bazaar. Ни один из них не уступает другому ни в поклонниках, ни в функционале. Видимо пришло время выяснить, кто же из них лучшим в драке. Судя по решимости участников — драка будет нешуточной :)

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

Компания Agitar Software предлагает довольно любопытную метрику для оценки качества программного кода. Формула с недвусмысленным названием CRAP позволяет оценить, воскликнет ли разработчик «Oh crap!» узнав, что за код ему выпало счастье поддерживать.

Хорошо, это может быть не Ruby. Выберите какой-нибудь другой язык. Выберите Erlang или даже Javascript.
Не важно — главное, чтобы он отличался от Java, и его изучение потребовало бы некоторых усилий.
Это поможет вам быть готовым к усвоению нового.

Зачем? Потому что изучение других языков сделает вас лучше, как Java разработчика. Серьезно.

Немного ранее я уже рассказывал о разработке компании Aptana — серверной платформы Jaxer, которая позволяет развёртывать приложения на JavaScript на стороне сервера, и объединять таким образом код клиентской и серверной стороны. Конечно, есть много спорностей в таком подходе, как и вообще применимости такого языка как JavaScript для разработки полноценных веб-приложений на сервере, но это не останавливает разработчиков — несмотря на ограничения, вполне можно разрабатывать интереснейшие приложения. Но вот уникальна ли эта платформа? Теперь нет.

Открытый проект Helma — написанная на Java платформа для исполнения серверных приложений на JavaScript. Сейчас поддерживается версия 1.7, однако с развитием движка Rhino, который отвечает во всех проектах подобного рода за интерпретацию JS, будем ожидать, что и вторая версия будет поддерживаться. Платформа обладает и встроенным веб-сервером, в качестве которого используется Jetty, и даже собственная объектно-ориентированная база данных (на основе XML), которая прозрачно интегрирована в платформу и позволяет сохранять и кешировать объекты между сессиями. Также есть встроенные средства отладки приложений, при этом все доступно через веб-интерфейс.

Посмотрел я на не слишком объемный блог JAVA и решил, что нужно поднимать его рейтинг. К тому же многие хабрики жалуются, что «хабр уже не тот». Возникла идея написать серию статей, продвигающих идею, что JAVA — это легко! Работаю я в среде интеграторов (берем готовые «жирные» системы, связываем в единый комплекс и продаем), и частенько возникает ситуация, когда что-то невозможно решить средствами интегрируемых систем. Тогда коллеги напрявляют прожектор в ночное небо и я иду им на помощь :). Поэтому частенько приходится использовать java в разных аспектах. Начнем с работы с SNMP. Протокол SNMP используется для управления сетью.

Представляю на суд сообщества перевод интервью Питера Муна с президентом фонда свободного программного обеспечения Ричардом Столлманом. В интервью Ричард повествует о том, что заставило его приступить к разработке свободной операционной системы GNU, объясняет свое видение понятий «свободное ПО» и «ПО с открытым исходным кодом» и их различия, призывает пользователей к борьбе с проприетарным ПО, а также просит не называть Linux просто Linux`ом.

JavaScript — очень динамический язык, в нём заложена возможность менять язык под себя и создавать удобные инструменты для дальнейшей работы. «Реализация классического наследования» — как раз один из таких инструментов. В данный момент я не представляю себе, как я программировал бы на JS без «классов».

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

В статье речь пойдет об имитации классического ООП и строгой типизации в JavaScript (< 2.0).

Я расскажу про JsOOP – мини-фреймворк для написания JavaScript-кода в объектно-ориентированном стиле.

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

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

Io

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

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

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

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

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