Язык Clojure отличается очень тесной интеграцией с Java. Прямое использование Java-библиотеки в приложении на Clojure — дело совершенно простое и обыденное. Обратная интеграция несколько сложнее. В этой статье указаны некоторые варианты интеграции кода на Clojure в Java-приложение.

DISCLAIMER: Все изложенные ниже приемы работают для меня, и не факт, что будут работать для вас. IMHO only, на истинность в последней инстанции не претендую.

В этом посте я соберу тезисно несколько приемов, которые помогают бороться с прокрастинацией и делать работу.

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

Отдых тела и ума

Сон и еда
По себе заметил, если не выспался — работать хочется в несколько раз меньше. Нужно найти для себя способ высыпаться, действуя из позиции Автора.

Второй важный пункт — еда. Для работы мозга — а работа в IT суть интеллектуальный труд — нужно много хорошей еды.
Если вы выспались и сыты, то силы должны быть, если их нет, идем дальше.

Активное тело, температура в помещении
Иногда нужно размять тело. Вовсе не так просто в СССР была производственная зарядка, о которой так бодро пел Высоцкий.

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

К хорошим постам «Код в стиле «дамп потока сознания»» и «Микро-рефакторинг, о котором мы так часто забываем».

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

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

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

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

Пройдемся по дизайну, серверным решениям, тестированию и аналитике.

Последние годы, с интересом почитывая о персональных поисковых системах в веселых желтых коробках имени Google, я периодически гуглил по словам GSA, Google Search Appliance, reverse engineering и, чего греха таить, hack, DIY, disk dump и т.п. Но ничего, кроме официальных пресс-релизов и переписки счастливых (?) обладателей с группой поддержки, я не встречал.

Иногда звучали на форумах робкие вопросы вроде «а как бы рута мне получить» или «попасть в GSA по ssh», но на все подобные вопросы ответ был один — только группа поддержки Google знает пароли. И никому не скажет. Удивительно, но я не встречал в интернете никаких попыток собрать «хакинтош» на движке Гугла, или по живому коду разобраться в алгоритме ранжирования страниц.

Ситуация слегка изменилась в 2008 году, когда на волне эйфории от виртуализации, Google выкатил VGSA – бесплатную виртуальную машину для Vmware с ограниченной до 50 тысяч документов лицензией. Впрочем, особого энтузиазма это в интернете не вызвало, в 2009 году проект был свернут и большинство ссылок в Гугле на VGSA стали возвращать 404 (заметьте – самим же Гуглом). Ссылку на релиз от 2008 года можно найти довольно легко. Ссылка на версию 2009 сохранилась лишь на паре китайских сайтов.

О том, как я поставил vgsa_20090210 на ESX 5.1 и увидел много чего интересного, можно прочитать ниже.

В продолжение темы, почему иногда нужно делать свой велосипед, хочу дополнить и расширить эти мысли причинами, по которым этого делать не стоит.

Причина 1. Вы не знаете, как такие велосипеды устроены

Посмотрите внимательно на предыдущий топик. Генри Форд — с детства изучал технику. Его сестра как-то сказала, что в детстве любую игрушку старались спрятать от него, потому что он ее тотчас разберет на винтики. Работал инженером в «Электрической компании Эдисона», был совладельцем «Детройтской автомобильной компании». Он точно знал, что это такое — автомобиль. Он точно знал технические нюансы. Он точно знал, что черная краска сохнет два дня, а любая другая — две недели! Ну не из-за прихоти же он однажды сказал, что автомобиль будет только черным.

Игорь Сысоев, прежде чем делать свой nginx, уже имел «достаточно неплохой опыт работы с Apache — и как у системного администратора, и как у программиста».

Знаете ли вы, что вам предстоит на пути создания своего велосипеда? Или просто готовы окунуться с головой, не проверив глубину водоема?

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

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

Самыми оперативными откликнувшимися на мои запросы были создатели Path, им и слово. В следующих постах расскажем про приложения Twitter, 4square, Pedometer, Bump, Shazam и другие.

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

GitHub-юзер yawnt собрал чудесную подборку ссылок для любителей драконов, языков и прочих вкусных внутренностей. А знающие камрады в комментариях наверняка поделятся с тобой и другими яствами.

Пишет yawnt следующее:

С каждым днём мне всё интереснее тема компиляторов, интерпретаторов и дизайна языков программирования в целом. И я решил поделиться с народом ссылками на собранные мной материалы (большую часть мне самому ещё предстоит прочитать :<). Надеюсь, кому-нибудь они окажутся полезными.

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.

Сегодня, 25 февраля, вышла версия 1.5.0 языка CoffeeScript. В ней впервые появилась базовая поддержка так называемого «грамотного» или «литературного» программирования (literate programming). Концепцию грамотного программирования придумал Дональд Кнут в 1981 году при разработке системы TeX. В отличие от исходного кода на обычном языке программирования, который включает в себя небольшие вкрапления комментариев, грамотное программирование подразумевает написание текстового документа на естественном языке с вкраплениями кода. Многие существующие системы грамотного программирования вообще не зависят от конкретного машинного языка.

Между Oracle и Google разгорелась нешуточная патентная война, стоимостью в 1 миллиард долларов, за право использовать Java в Android.

Но Java не единственный способ создания приложений, на самом деле даже не самый лучший. Как альтернативу мы предложили С#, добившись высокой производительности и низкого потребления батареи. Наша новая платформа — это открытая реализация .NET Framework, позволяющая разработчикам писать код на C#, адаптировать его под Java системы и переиспользовать часть кода для iOS и Windows Phone.

Вступление

Как справедливо заметил Fred Brooks, серебряной пули, способной поразить зверя разработки программного обеспечения, не существует. Пока возникают новые требования, идеи и находятся новые баги, программы живут и изменяются. Путь, который проходит код от версии к версии, может быть крайне сложен и извилист. К его созданию причастно много людей: разработчики, тестировщики, бизнес-аналитики, заказчики и т.п. Несмотря на то, что существует много разных видов разработки – аутсорсинг, продуктовая разработка, open-source и т.п., проблемы, стоящие перед командой, остаются примерно одинаковыми. Программное обеспечение – вещь сложная, потребитель хочет получить его как можно быстрее (и дешевле). Качество при этом должно быть приемлемым. Перед командой разработки стоит серьезная задача – наладить эффективное взаимодействие. Одним из самых главных средств коллаборации внутри команды разработчиков является сам код, который они пишут.

Эта статья — попытка ответить на вопрос 11-летнего олимпиадника: «Зачем нужны паттерны?» Ещё не отправил, выношу на общий суд и прошу любой критики. Цель — не дать исчерпывающий ответ, а вызвать новые вопросы.

Итак

Как учат программированию в школе? Вам дают формочки и учат делать куличики из песка. Это хорошо, надо ведь с чего-то начинать.

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

Есть большая разница между принципом и хорошей практикой.

Лучшие практики — субъективны и зависят в основном от контекста, в то время как принципы — вечны и универсальны.

После написания статьи «Чем больше я знаю, тем меньше я знаю» (англ.), я получил несколько писем о том, что существуют некоторые практики, которым нужно следовать абсолютно в любом процессе разработки ПО.

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

В качестве введения

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

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

В данной статье будет показано как можно реорганизовывать код написанный в «простом» JQuery стиле в код на Backbone, с использованием представлений, моделей, коллекций и событий. Реорганизация будет постепенной, так чтобы этот процесс дал четкое понимание основных абстракций в Backbone. Статья рассчитана на тех кто использует JQuery и хотел бы познакомится со схемой MVC для клиентского кода.

Рад сообщить, что после более полугода разработки в свет вышел Emmet (бывший Zen Coding) v1.0.

Emmet — это инструмент для ускорения работы с HTML и CSS. В основе проекта лежит механизм динамических аббревиатур, которые разбираются «на лету» и из которых генерируется готовый фрагмент кода. Для написания аббревиатур используется синтаксис, похожий на CSS-селекторы, но с некоторыми дополнениями, специфическими для создания кода. Например, вот такая аббревиатура:

section>h2+ul.nav>li.nav-item$*5>a

простым нажатием клавиши превращается в:

<section>
    <h2></h2>
    <ul class="nav">
        <li class="nav-item1"><a href=""></a></li>
        <li class="nav-item2"><a href=""></a></li>
        <li class="nav-item3"><a href=""></a></li>
        <li class="nav-item4"><a href=""></a></li>
        <li class="nav-item5"><a href=""></a></li>
    </ul>
</section>

30 января компания Research In Motion представила смартфоны на новой ОС BlackBerry 10. Приложений в BlackBerry App World пока существенно меньше, чем в Google Play или App Store, например. Можно успеть занять нишу, выпустив версию своего замечательного приложения и под эту ОС. Тем более, что это не требует больших трудозатрат.

Итак, как становится ясно из информации для разработчиков, существует несколько способов создания приложений под BlackBerry 10:

• нативные приложения на C/C++;
• веб-приложения на HTML5;
• Adobe AIR и ActionScript;
• Android API 2.3.3 runtime;
• Java BlackBerry runtime.

Для превращения Android-приложения в BlackBerry-версию также существует несколько способов: использование re-packaging tools, для переупаковки уже имеющегося apk, или использование непосредственно исходников Android-приложения для более вдумчивого и тщательного портирования с последующей сборкой под BlackBerry с помощью BlackBerry Native SDK. Рассмотрим первый вариант, как наиболее быстрый и простой.

С какой целью и для кого

Данная статья является кратким изложением основных преимуществ DVCS.
Я собрал воедино все доводы о пользе перехода на DVCS (а именно mercurial) и постараюсь доступно изложить это для тех у кого не было практического опыта работы ни с одной из DVCS.