Некоторое время назад мне пришла в голову идея сделать логирование в Java более дружелюбным, простым и в тоже время достаточно гибким в настройке. Такие требования справедливы пожалуй, в средних и малых проекта, где можно обойтись без громоздкого log4j. Буквально за неделю, идея переросла в простенькую Java библиотеку с ни менее простым названием — logy.

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

import static logy.Logy.*;

public class Test {
  public void test() {
    String s[] = {"a", "b"};
    warn("Can't find", quote(upper("c")), "in", group(quote(upper(scalar(s)))));
  }
}

Вывод:
29.06.2012 1:19:25 Test.test [WARN] :: Can't find "C" in ["A", "B"]

Как по мне, выглядит очень читабельно, благодаря синтаксическому сахару, DSL-like API и динамическому определению параметров логирования в момент вызова (читай без дополнительных полей public static final Logger logger = ... в классе).

Как известно, наш проект Jelastic создан с целью облегчить жизнь разработчикам, и, конечно же мы всегда прислушиваемся к их пожеланиям, изучаем их психологию, мышление и другие аспекты. Ниже мы публикуем статью одного из ведущих компьютерных публицистов — Нейла МакАлистера — которая ранее публиковалась в InfoWorld и нашем английском блоге.
Некоторые из положений статьи могут показаться спорными (например, мы в каком-то смысле сами «оффшорные» с нашей разработкой в России и Украине), но все они крайне интересны.

Оказывается, даже столь рациональные люди с развитой логикой, как разработчики, верят мифам. Некоторые программисты верят в то, во что они хотят верить, вопреки всему.
Например, классическим заблуждением является мнение, что можно ускорить разработку проекта за счет добавления большего количества разработчиков. Фредерик Брук развеял этот миф еще в 1975 году в своей книге «Мифический человеко-месяц».
Брук считал, что добавление разработчиков в уже достаточно развитый проект никак не ускорит процесс. Напротив, это замедлит процесс разработки еще больше. По сути это опровергает множество общепринятых понятий относительно управления программными проектами.
Конечно, некоторые примеры Брукса кажутся сегодня устаревшими, но общая идея и сейчас актуальна. Его доводы уж очень убедительны. 37 лет спустя, мифическое мышление продолжает преобладать среди программистов. Мы продолжаем делать те же ошибки.
Вот несколько примеров современных мифов о программировании, многие из которых берут начало с более давних заблуждений.

Как известно, с использованием фреймворка Qt написано немало программ, причём отечественных среди них в последнее время становится всё больше. Итак, что же было написано в России с использованием этого фреймворка?

Kaspersky Internet Security

Kaspersky Internet Security 2012 – решение для обеспечения оптимального уровня безопасности. Инновационная гибридная защита мгновенно устраняет вредоносные программы, спам и другие интернет-угрозы, экономя ресурсы компьютера за счет комбинации облачных и антивирусных технологий.

В папке программы обнаружил следующие модули: qtcore, qtdeclarative, qtgui, qtnetwork, qtscript, qtsql, qtwebkit.

2ГИС для iOS и Android

2ГИС – бесплатный электронный справочник организаций с картой города. 11 550 000 пользователей ПК в более чем 150 городах России и Украины регулярно используют 2ГИС в личных целях и для решения бизнес-задач.

Пруфлинк: «Оффлайновая версия 2ГИС разработана с использованием фреймворка Qt 4.8 и имеет нативный интерфейс, созданный в соответствии с Apple Human Interface Guidelines».

Открою не Америку, но шкатулку Пандоры: в Java-коде много бойлерплейта. Типовые геттеры, сеттеры и конструкторы, методы ленивой инициализации, методы toString, hashCode, equals, обработчики исключений, которые никогда не выбрасываются, закрывалки потоков, блоки синхронизации. Проблема заключается даже не в том, чтобы написать всё это — современные среды разработки справляются с такими задачами нажатием нескольких клавиш. Сложность в поддержании бойлерплейта в актуальном состоянии по мере внесения модификаций в код. А в некоторых случаях (многопоточность, реализация методов hashCode и equals) и сам шаблонный код написать без ошибок — далеко не простая задача. Одним из решений проблемы является генерация кода, и в этой статье я расскажу про проект Lombok — библиотеку, которая не только может избавить вас от бойлерплейта, но и сделать это максимально прозрачно, с минимальной конфигурацией и, что немаловажно, с поддержкой на уровне среды разработки.

Эта статья открывает серию статей — если окажется, что Хабраколлеги сочтут ее интересной, ибо первое правило публичных выступлений гласит: рассказывай людям о том, что им интересно!

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

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

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

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

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach"), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.

Проапгрейдил недавно компьютер на LGA2011, на коробке от относительно недешевой платы красовалась надпись «супер пупер звук, 110Дб вся фигня». Отлично подумал я, хороший звук никогда не помешает. Следующие 2 дня я неистово гнал железо, и все было хорошо. А потом вернулся к обычной работе, и естественно, к рабочей музыке. Тихо. Нет. ТИХО! 100% громкости едва хватало для комфортной громкости с моими обычными 32-х омными наушниками (Sennheiser HD 448, отличающихся не самой высокой чувствительностью), а если запись была сделана с низким уровнем сигнала — то хоть волосы вырывай.

От безысходности начал было даже слушать через bluetooth A2DP адаптор, но само собой и качество и аккумуляторы (~6 часов) вгоняли в печаль…

Стало ясно что жить так больше нельзя…

Простое и полезное преобразование компьютерного БП.

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

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



Странно, но методики, которые родились непосредственно в области разработки ПО совсем не похожи на пришедшие извне.

Например достаточно простой SCRUM, описание которого вполне можно уместить на листок A4, но которым пользуется CERN. Или Agile, который можно описать десятом абзацев где содержатся весьма общие и идеалистические принципы в соответствии с которой был сделан GitHub и много других клевых штук. Можно ли их использовать в строительстве? А при создании самолетов?

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

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

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



Если искать аналогии в плане управления, то весьма схожем с производством ПО может показаться строительство. Мало того, менеджеров по разработке ПО нередко знакомят с управлением проектированием и строительством зданий и инженерных сооружений.

Однако, происходит некоторая подмена причин этого знакомства. Да, эта область в чем-то похожа, в первую очередь наличием понятий “требования”, “проектирование”, “проект”, “строительство” (construction), “контроль качества”, “человеко-часы”, “работы”, “сроки”, а сам процесс развивается от экономической потребности и идеи до некого конечного продукта. Но основная причина того, что строительство является хорошей аналогией в том, что это наглядная аналогия.

(В качестве иллюстрации фотография проекта А.Гауди «Sagrada Familia», степень выхода которого за сроки и бюджет до сих пор не могут даже приблизительно оценить)

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



Несколько дней назад я размышлял, почему так получилось, что тщательно прописанный и формализованный проект в очередной раз со свистом вылетел из сроков и бюджета, превысив их в разы. Иногда бывает, что проекты ведут себя по другому, но чаще происходит именно так. И это мало зависит от того, какую методику я использую для оценки объема работ и самой разработки. Даже McConnell, которого я считаю серьезным авторитетом в области разработки ПО, в начале книги Software Estimation: Demystifying the Black Art констатирует то, что простые методики оценки размера проекта удивительным образом оказывается ничуть не хуже сложных и испытывают те же самые проблемы. Возможно этот вывод можно распространить не только на методики оценки.

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

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

(на иллюстрации персонаж фильма «Железный человек 2» Иван Ванко в момент произнесения фразы «Ваш софт — говно»)

1. Индустрия на стероидах

    Наверняка многие из нас хоть раз думали про себя: «Черт побери, и везет же этим американцам!». Это касается многого, от магазинов с доставкой «только в пределах 48 континентальных штатов» до вполне серьезных контрактов, которые срываются только потому, что потенциальный заказчик в США категорически не желает иметь дело с иностранцами.

    В этой статье я попробую осветить процесс создания и администрирования американской корпорации для резидента РФ. Наверняка многие из фактов для самих американцев покажутся тривиальными, однако для жителя России все куда сложнее — увы, это данность. Чтоб не сказать — это Родина, сынок. Оговорюсь сразу — я все это проделал более 2 лет назад, так что, некоторые детали могут быть не совсем актуальны. Но вряд ли что-то поменялось принципиально.

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

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

Вот уже подоспела и вторая часть статьи.


1. Нестатические блоки инициализации.

Всем, я думаю, известно, что в Java существуют статические блоки инициализации (class initializers), код которых выполняется при первой загрузке класса.

class Foo {
	static List<Character> abc;
	static {
		abc = new LinkedList<Character>();
		for (char c = 'A'; c <= 'Z'; ++c) {
			abc.add( c );
		}
	}
}

Но существуют также и нестатические блоки инициализации (instance initializers). Они позволяют проводить инициализацию объектов вне зависимости от того, какой конструктор был вызван или, например, вести журналирование:

class Bar {
	{
		System.out.println("Bar: новый экземпляр");
	}
}

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

Map<String, String> map = new HashMap<String, String>() {{
	put("паук",  "арахнид");
	put("птица", "архозавр");
	put("кит",   "зверь");
}};

Очень даже мощное средство, не находите?

JFrame frame = new JFrame() {{
	add(new JPanel() {{
		add(new JLabel("Хабрахабр?") {{
			setBackground(Color.BLACK);
			setForeground(Color.WHITE);
		}});

		add(new JButton("Торт!") {{
			addActionListener(new ActionListener() {
				public void actionPerformed(ActionEvent event) {
					System.out.println("Хабрахабр - торт!");
				}
			});
		}});
	}});
}};

Остальные четыре пункта под катом.

Хорошие новости для Java разработчиков. Теперь вы можете собирать свои проекты прямо в Jelastic, уже нет необходимости в локальной сборке и загрузке WAR архива.
Что это дает? Во-первых, процесс деплоя происходит гораздо быстрее и меньше расходуется трафик. Архив может быть довольно большим. Раньше вы были вынуждены перезаливать его в ваше окружение каждый раз после каких-либо модификаций, теперь Jelastic сам берет измененный код с репозитaриев контроля версий и восстанавливает приложение в облаке.
Во-вторых, вы получаете все преимущества облака и продолжаете использовать свой компьютер без всяких дополнительных нагрузок.
Чтобы создать окружение с Maven просто кликните по соответствующей пиктограмме в окне Environment topology.

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

Малоизвестные особенности Java. Первая часть

6. Конфликт имён.

Если импортированы несколько классов с одним и тем же именем из разных пакетов, возникает конфликт имён. В таком случае при обращении к классу следует указывать его квалифицированное имя, то есть полное имя, включая и имя пакета, например java.lang.String.

Неужели ничего нельзя с этим поделать? Оказывается можно. Следующий код скомпилируется без проблем, несмотря на то, что класс List присутствует и в пакете java.awt, и в пакете java.util:

import java.awt.*;
import java.util.*;
import java.util.List;

public class Класс {
	public static void main(String... аргументы) {
		List простоСписок = Collections.emptyList();
		System.out.println(простоСписок);
	}
}

Достаточно дополнительно импортировать необходимый класс, java.util.List в данном примере.

Тут, как вы заметили, используются кириллические идентификаторы. Да! Для кого-то это станет откровением, но Java… такая Java. Идентификатор может состоять из совершенно любых букв, помимо цифр, знаков подчёркивания и валюты США (однако последний знак ($) использовать не рекомендуется, он предназначен для системных нужд). Но оно нам надо? Разве только в целях обфускации. Только представьте себе, сколько разных идентификаторов можно сгенерировать всего-то из символов «А» английского, русского и греческого алфавитов…

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

Блог на Jekyll и Github

Для ведения блога существует множества прекрасных решений: posterous, blogger, wp… Выбирать можно и выбирать нужно, если вы хотите вести свой блог конечно. Сейчас я расскажу об относительно новом гик-решении в блоговедении — это Jekyll блог на базе Github.
Jekyll — это простой генератор статичных сайтов, аля блог. Он содержит шаблоны для создания логики сайта. Благодаря Github Pages — сайт можно хостить на Github. Это просто. Создаете репозиторий «Название сайта».github.com и публикуете туда код вашего сайта на Jekyll. Commit+Push и Github автоматически обновляет ваш сайт.

На StackOverflow часто задают вопросы, подробно освещённые в документации. Ценность их в том, что на некоторые из них кто-нибудь даёт ответ, обладающий гораздо большей степенью ясности и наглядности, чем может себе позволить документация. Этот — один из них.

Вот исходный вопрос:

Как используется ключевое слово yield в Python? Что оно делает?

Например, я пытаюсь понять этот код (**):

def _get_child_candidates(self, distance, min_dist, max_dist):
    if self._leftchild and distance - max_dist < self._median:
        yield self._leftchild
    if self._rightchild and distance + max_dist >= self._median:
        yield self._rightchild

Вызывается он так:

result, candidates = list(), [self]
while candidates:
    node = candidates.pop()
    distance = node._get_dist(obj)
    if distance <= max_dist and distance >= min_dist:
        result.extend(node._values)
        candidates.extend(node._get_child_candidates(distance, min_dist, max_dist))
        return result

Что происходит при вызове метода _get_child_candidates? Возвращается список, какой-то элемент? Вызывается ли он снова? Когда последующие вызовы прекращаются?

** Код принадлежит Jochen Schulz (jrschulz), который написал отличную Python-библиотеку для метрических пространств. Вот ссылка на исходники: http://well-adjusted.de/~jrschulz/mspace/