В соответствии с календарем релизов осталось всего несколько недель до заморозки списка фич следующего релиза git (1.7.10), в который войдет улучшение работы git merge, нарушающее обратную совместимость и ставящее «под удар» тех, кто использует merge в своих скриптах.
Мы решили последовать совету Джейка Эджа (Jake Edge): «Большинство свободных проектов обсуждают планируемые изменения до их реализации и дают пользователям возможности протестировать новые фичи задолго до релиза. Лучшая помощь проекту на этом этапе — четко обоснованные, конкретные описания существующих проблем, отсутствующей функциональности и т.д., а не бесконечный поток сообщений „Project XYZ ОТСТОЙ!!!11“ в списках рассылки или комментариях»

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

QML технология красивая и радует глаз. Меня она очень заинтересовала, и я решил ее освоить. Но не тут то было, ибо я оказался тупым и беспомощным. Нигде в сети не нашел примера «для чайников» (наверно плохо искал), чтобы с нуля построить простейшее приложение QML и C++ в связке. Везде чего-то не хватало: или не учитывался Qt Creator, или код выдавал ошибки, или отсутствовали целые моменты, которые пользователи должны были сами знать. Официальная документация и примеры здесь на хабре также были с этими недостатками. Вот и решил после долгих попыток и ошибок написать такую статью для начинающих с подробнейшим описанием.

Задача. Нужно написать программу QML в связке с С++, где
1. На форме располагается кнопка, строка ввода, и поле вывода.
2. Требуется считать из строки ввода число, прибавляется 1, и ответ выводится в поле вывода.
3. Интерфейс написан на QML.
4. Функционал на С++, то есть нам нужно обеспечить взаимосвязь между QML и C++: кнопка QML вызывает С++ функцию, а функция меняет свойства QML объектов.

После реализации пары проектов под Android, стало понятно, что, несмотря на их небольшие размеры и кажущуюся простоту, без автоматизированных сборок и тестирования не обойтись. Родилось желание получить следующие возможности:

• unit тестирование,
• интеграционное тестирование,
• тестирование интерфейса,
• тестирование этих типов тестов на различных версиях Android и конфигурациях девайсов,
• рассылка по email в случае сломанного билда;
• таже не помешает автоматическая сборка релизов.

Два с половиной месяца назад я написал о своем приложении.
За это время я позакрывыл пару десятков issue, добавлял функционал, выполнил и пофиксил пожелания пользователей Yeah, kekekeks.
В кратце, что добавилось:

• Для исходников и diff теперь плавающие скролы
• Для diff плавающие заголовки
• Бинарные файлы распознаются более качественно (ICU4J)
• Поддержка http для git
• Оповещения на почту (apache camel)
• Обновил доку
• Мелкие изменения в gui и багфиксы

А теперь о том, как мое приложение можно использовать. http я пилил не просто так…

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

Сразу хочется сказать, что я не хочу останавливаться на теоретических аспектах построения ИТ-систем (ITIL, ITSM). В них описываются стандарты и подходы, к которым необходимо стремиться (что я стараюсь делать изо всех сил), но которые на практике не совсем все удается реализовать

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

Аутсорсинг — это ОТВЕТСТВЕННОСТЬ ЗА ПРОЦЕСС, которую берет на себя сторонний подрядчик.

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

Такое письмо я получил от Шона Сильвы прошлой ночью:

Я просматривал ваш код для проекта npm.js (в частности, вот этот файл: https://github.com/isaacs/npm/blob/master/lib/npm.js), и заметил, что вы выравниваете запятые под ‘r’ в выражениях var, и под [ и { в литералах массивов/объектов. Мне очень нравится такой способ форматирования, но я не решаюсь его использовать, так как большинство ресурсов о js насаждают страх перед хаосом, который воцарится в коде из-за автоматической расстановки точек с запятой, если вы не будете заканчивать строки чем-нибудь, что предполагает продолжение.
Безопасно ли располагать запятые таким образом в «браузерном» коде, или это только в node возможно?

Я написал несколько абзацев, и решил сократить их до следующего ответа:

Да, это полностью безопасно, и это совершенно валидный JS, понимаемый каждым браузером. Closure compiler, yuicompressor, packer, и jsmin — все могут правильно минифицировать его. Производительность нигде не просядет.
Мне жаль, что вместо того, чтобы обучать вас, лидеры сообщества этого языка прививали вам ложь и страхи. Это позор. Я рекомендую изучить, как на самом деле терминируются инструкции в JS (и в каких случаях они нетерминируемы) — и вы сможете писать код, который сочтете прекрасным.

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

Особо вероятно изобретение велосипеда, когда рост сложности приложения происходит постепенно и в некотором смысле незаметно. Сложное приложение обычно является богатым приложением (rich), его элементы и особенности специфицированы W3C www.w3.org/TR/backplane. Известный JavaScript-евангелист Addy Osmani так дополнительно определяет сложное приложение: “По-моему, крупное JavaScript приложение есть нетривиальное приложение, требующее значительных усилий разработчика для поддержки, причем наиболее сложное оперирование обработкой и отображением данных ложится на браузер” (http://addyosmani.com/largescalejavascript/).

История этой статьи началась лет как минимум семь назад когда поработав в одной немецкой web-компании я перешла под крылышко крупного конечного заказчика и начала работать удаленно.

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

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

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

Привет хабралюди! Постараюсь написать коротко.

I.

Сначала о ядре. В тестинге появился новый LTS!!!

— имя пакета изменилось на linux-lts
— конфиг синхронизован с последним 3.0.x
— nouveau-drm-lts выкинут нафиг — оно теперь в ядре
— изменилось имя ядра: vmlinuz-linux-lts
— изменились имена initramfs: initramfs-linux-lts.img

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

Известно, что следуя идеям старой школы, а именно, добавляя ссылки на JS и CSS в страницы, может обернуться большим временем загрузки страницы. Браузер отображает страницу по мере скачивания, но останавливается, если натыкается на тег script со ссылкой, до того момента, пока скрипт не будет загружен и выполнен. Сайты стали использовать всё большее количество скриптов, начальное отображение страницы занимает всё больше времени, к примеру, на этой странице, которую вы читаете, 13 скриптов, 7 из которых находятся в head'е. Ко всему прочему, некоторые браузеры по-прежнему придерживаются ограничений на одновременное количество загрузок с одного хоста.

Сразу предлагаю принять, что все JS файлы минимизированы, и передаются в сжатом виде.

Существует несколько решений, как то:
— поместить стили и скрипты прямо в страницу;
— установка аттрибутов async/defer тегу script;
— склеить все скрипты в один файл;
— помесить ссылки на скрипты в конец body;
— разместить все файлы на CDN/на разных хостах;
— свой вариант…

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

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

Введение

Причиной написания данной статьи послужила необходимость создания программы для системы Android, с помощью которой можно отправлять данные заказа в виде SMS сообщений владельцам интернет магазинов о том, что был совершен заказ товаров или услуг. Ранее мною использовалась система включающая GSM-модем и программу написанную на языке С++, использовавшая AT-команды для общения с модемом и библиотеку gloox для получения сообщений по протоколу XMPP, на стороне web-сайта использовалась библиотека xmpphp, для отправки данных заказа. При такой схеме приходилось держать включенным компьютер постоянно, так как система приема заказов работала круглосуточно, соответственно отсюда дополнительный расход электроэнергии, шум от вентиляторов ночью и постоянный контроль интернет соединения.

Steven Sinofsky опубликовал статью в которой объясняется, почему в Internet Explorer 10 для Windows 8 не будет поддерживаться Adobe Flash.



Новый IE по умолчанию будет запускаться в режиме plug-in free, в котором недоступны plug-in'ы (в том числе plug-in для отображения Flash) и встроенные ActiveX-компоненты.

Использование Rebar

Этот туториал может содержать устаревшие сведения, так как Rebar очень активно развивается без сохранения совместимости с предыдущими версиями.

При разработке на Erlang часто приходится собирать зависимости из разных источников, следить за их нужными версиями, создавать OTP-релизы для распространения проектов. Дела достаточно рутинные и неприятные. Для того, чтобы разработка меньше доставляла неприятных моментов, компанией Basho был создан очень удобный инструмент — Rebar. В этой статье я постараюсь раскрыть преимущества от его использования на реальном примере с использованием сторонних зависимостей и созданием конфигурируемых OTP-релизов.

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

Поискав на Хабре по теме Erlang/Эрланг, понял, что тема освещена мало, есть всего пара действительно хороших статей на тему языка (например, отличная статья от создателя языка в переводе alex_blank What's all this fuss about Erlang? написанная понятным, доходчивым языком). Именно поэтому хочется остановиться сначала на самом языке и его отличиях от традиционных языков.

Добрый день! Меня зовут Антон Щастный.

Это моя очередная статья, посвящённая разработке веб приложений на Java. Хочу предложить вам сделать небольшую систему учёта клиентов, написанную с использованием фреймворка Spring и библиотеки Hibernate.

Что будет в приложении:

Будет простой менеджер контактов, позволяющий добавлять в базу новые записи, просматривать имеющиеся, удалять ненужные. Сведения будут храниться в базе данных. Доступ к приложению – через веб, с аутентификацией и авторизацией пользователей.

Что будем использовать:

• веб фреймворк Spring MVC,
• фреймворк Spring Security,
• ORM библиотеку Hibernate,
• MySQL в качестве СУБД.

Инфраструктура:

• редактор SpringSource Tool Suite,
• сборщик проектов Maven,
• система логгирования Log4j,
• постоянное подключение к интернету.

В моей предыдущей статье о Spring MVC был упущен ряд моментов по использованию аннотаций в Java-коде и применению Maven для сборки проекта. В данной статье я попытался исправить упущение.

Цель статьи – показать начинающим веб разработчикам совместное использование различных технологий платформы Java.

Интервью с Джоном Резигом, опубликованное 25 июля на usesthis.com

Кто вы и чем занимаетесь?

Я JavaScript программист. Я работаю в Khan Academy, разрабатываю обучающую систему следующего поколения. Я создатель и главный разработчик JavaScript библиотеки jQuery и автор двух книг о JavaScript – «Pro JavaScript Techniques» и «Secrets of the JavaScript Ninja».

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

Я попытаюсь описать эти проблемы и предложить их решение. Итак, поехали.

«Под Windows можно писать для iPhone?»
Анонимный разработчик

«Мы не планируем публиковаться в AppStore, это ведь возможно? И еще мы хотим версию под Android...»
Анонимный заказчик

Если вы решились разрабатывать приложения для iPhone/iPad, то, скорее всего, вас заинтересуют следующие вопросы:

• как можно заработать на приложениях?
• как зарегистрироваться в iOS Developer Program и что дает регистрация?
• обязательно ли нужен Mac?
• какие инструменты можно использовать для разработки?

В прошлой моей статье про скорость работы с данными GAE был встроен графический счетчик показов. Каждый мог видеть значение счетчика и израсходованные ресурсы CPU. Как я уже говорил, счетчик был довольно «тяжелым»: создаваемая им нагрузка эквивалентна отображению на странице 1000 записей из базы данных без использования кеширования.

Эксперимент со счетчиком оказался весьма полезным, а его результаты несколько неожиданными для меня (отличными от запросов с одного IP-адреса). Хочу поделиться результатами эксперимента и поставить новый эксперимент, уже с учетом пройденных ошибок. Кстати, исходный код нового графического счетчика доступен для всех и приведен в статье.

Хочу представить Хабрасообществу наш новый проект — 42tasks.com, кросс платформенный GTD сервис. Почему 42tasks? Потому что все более менее приличные домены уже были заняты а "42 — Ответ на главный вопрос жизни, вселенной и всего такого".