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

Вводная: веб-сайт, у которого не экранируется один из параметров в простом SELECT запросе. При этом все ошибки перехватываются, обрабатываются и выводится скромное «Нет данных» или «Произошла ошибка».

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

Но, что на самом деле можно сделать в данной ситуации?

Предисловие

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

Программа написана с помощью низкоуровневого языка C++, потому что я действительно хотел понять, как же это все работает изнутри. Если вы тоже хотите начать изучение компьютерного зрения, то для этого пригодиться библиотека OpenCV. На CodeProject вы сможете найти несколько уроков по ней. Изображение с веб-камеры получается с помощью исходного кода Вадима Горбатенко (AviCap CodeProject).

Хотя метод был разработан и представлен в 2001 году Полом Виолой и Майклом Джонсом [1, 2], он до сих пор на момент написания моего поста является основополагающим для поиска объектов на изображении в реальном времени [2]. По следам топика хабраюзера Indalo о данном методе, я попытался сам написать программу, которая распознает эмоцию на моём лице, но, к сожалению, не увидел на Хабре недостающей теории и описания работы некоторых алгоритмов, кроме указания их названий. Я решил собрать всё воедино, в одном месте. Сразу скажу, что свою программу успешно написал по данным алгоритмам. Как получилось рассказать о них ниже, решать Вам, уважаемые Хабрачитатели!

Коллеги, добрый день!

Сегодня поговорим о причинах, побуждающих создавать и внедрять методики и инструменты обеспечения качества, заглянем в историю проблемы, осветим известные риски и постараемся «устаканить» в сознании выигрышную стратегию обеспечения достаточного качества веб-решения. В заключении я расскажу о новом инструменте в 11 версии платформы Битрикс — «Мониторе качества».

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

Основное:

• Численность команды разработчиков — 7 человек;
• Длительность спринта — примерно две недели;
• Стендапы каждый день;
• Организацонные вещи хранятся в Acunote, google docs и MindMap;
• Код хранится в SVN, новая фича — новая ветка, над одной фичей трудятся несколько разработчиков;
• Тестирование — через unit-tests.

Два года — это очень длинный марафон, поэтому каждому важно правильно получать задачи и видеть конкретные результаты их выполнения. Для этого мы ввели систему коротких периодов, различения целей и задач плюс предельной конкретизации последних. Самая короткая ставящаяся задача — 2 минуты, самая длинная — 3 часа.

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

У нас в Siyelo две распределённых команды, одна в Кейптауне, вторая в Скопье. Нам приходится придумывать, как заниматься удалённым парным программированием между офисами. Существует много возможностей (отличный обобщающий пост здесь).
Раньше мы постоянно пользовались Skype'ом для разделения экрана, но у нас при этом возникали следующие проблемы:

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

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

Малоизвестные особенности 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. Идентификатор может состоять из совершенно любых букв, помимо цифр, знаков подчёркивания и валюты США (однако последний знак ($) использовать не рекомендуется, он предназначен для системных нужд). Но оно нам надо? Разве только в целях обфускации. Только представьте себе, сколько разных идентификаторов можно сгенерировать всего-то из символов «А» английского, русского и греческого алфавитов…

Готовясь к собеседованию, я решил освежить память да и вообще поискать каверзные и малоизвестные нюансы языка 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("Хабрахабр - торт!");
				}
			});
		}});
	}});
}};

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

В посте речь пойдет о моем опыте встраивания XML-RPC интерфейса в утилиту, написанную на C. Интерфейс должен предоставлять доступ к статитстике и результатам работы утилиты. Одно из требований к интерфейсу — поддержка ответов в формате gzip, в целях экономии трафика. Мне очень хотелось обойтись малой кровью и вот что из этого получилось.

Предисловие

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

Транзистор, как и диод, основан на явлении p-n перехода. Желающие могут освежить в памяти физику протекающих в нем процессов здесь или здесь.

Необходимые пояснения даны, переходим к сути.

Привет Хабр. В данной статье я бы хотел поделиться опытом работы с GSM модемом, а точнее опытом отправки SMS сообщений. Ниже будет описана реализация программы на Delphi для отправки SMS сообщений, а так же чтение и удаление входящих/исходящих сообщений с модема. В моём случае это был модем HUAWEI от MTS. Всех кого заинтересовал, прошу под кат.

Некоторое время назад меня попросили настроить в удаленном филиале простейшую балансировку трафика. Работают они, бедолаги, через ADSL, и отправка электронных писем большого объема (сканы документов) забивает им весь обратный канал, что приводит к проблемам в работе с офисными онлайн-программами через VPN.
В качестве шлюза у них используется Linux (Fedora). До этого я пару раз видел, как подобная балансировка настраивается через ipfw на FreeBSD, а так как знаю механизм iptables достаточно хорошо, не ожидал особых проблем. Но поискав в Интернете, я был неприятно удивлен тем, что iptables мне тут совсем не помощник. И знания о порядке прохождения пакетов через его таблицы и правила мне почти не пригодятся. Нужно изучать tc из пакета iproute2.

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

В октябре на хабре появилась замечательная статья про работу HashMap. Продолжая данную тему, я собираюсь рассказать о реализации java.util.concurrent.ConcurrentHashMap.
Итак, как же появился ConcurrentHashMap, какие у него есть преимущества и как он был реализован.

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

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

Ты уже три года проработал программистом, ты (возможно) всё более и более пристально смотришь в сторону проджект менеджмента. Твой ПМ уже не царь, и не бог, и его работа не кажется тебе сложной и непонятной. Ты видишь, что работаешь намного больше его, а он ленится сделать тебе Code Review и похвалить за оригинальную интеграцию сторонней библиотеки. Он даже не смотрит на твой идеальный код в сложнейшей стыковке кривого API и мутной бизнес-логики. И ты точно знаешь, что, когда тебе улыбнётся удача руководить проектом, ты всё будешь делать лучше. Ты будешь бережнее следить за своими девелоперами, ревьювить каждый их класс, хвалить за удачные решения и порицать за очевидные ошибки.

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

Большинству разработчиков известно, что сборщик мусора в Java не является универсальным механизмом, позволяющим программисту полностью забыть о правилах использования памяти и о том, в каких случаях осуществляется его работа. Ниже описаны типичные случаи утечки памяти в java-приложениях, встречающиеся повсеместно.
Итак, о чём должен помнить каждый java-программист.

Архитектура и платформа проекта Одноклассники

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

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

Buffered Streams

//медленно
InputStream is = new FileInputStream(file);
int val;
while ((val = is.read()) != -1) {
}
//быстро
InputStream is = new BufferedInputStream(new FileInputStream(file));
int val;
while ((val = is.read()) != -1) {
}

Казалось бы — очевидная истина, неправда ли? Но как показал чужой код и опыт собеседования кандидатов, часть разработчиков определенно не понимает в чем преимущество буферизованных стримов. Кто до сих пор не разобрался — метод read() класса FileInputStream:

public native int read() throws IOException;

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

System.arraycopy(src, srcPos, dest, destPos, length);

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

Замечательные статьи публиковались в последнее время, хотелось бы добавить ещё несколько абзацев по данной теме.

Уважаемые авторы предыдущих топиков как-то упускали тот момент (или мне показалось? или это само-собой подразумевается?) что exceptions возникли как инструмент для решения весьма утилитарной задачи —

Так уж сложилось, что до недавнего времени все проекты, написанные мною на Java я собирал, кхм, за меня собирал NetBeans. И меня такой расклад вещей вполне устраивал: после сборки всего проекта всё аккуратно складывалось в директорию dist со всеми подвязанными библиотеками, оставалось накидать туда пользовательской документации, необходимых native-библиотек (например от Firebird) и в путь, т.е. всё в архив. Когда то я делал это вручную, потом велосипедом, а потом уже Maven'ом. Под катом находится история о том, как же я пришел в стан maven и что из этого получилось.