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

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

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

Что такое ESB Toolkit и чем он интересен

ESB Toolkit — это набор инструментов для BizTalk сервера, который позволяет упростить разработку интеграционных приложений.
Несмотря на то, что это мощный инструмент, позволяющий создавать серьезные продукты, первое, чем он подкупает – низкий «порог вхождения» в тему разработки для BizTalk. Многие задачи, сложно решаемые оркестровками, легко решаются с помощью ESB Toolkit.
Майкрософт создала прекрасную документацию, где приведены примеры решения множества типичных задач. Но на своем примере я понял, что эта документация становится полезной, когда появилось общее представление о работе с этим инструментом. Видимо, срабатывает условный рефлекс ленивого программиста – не читать документацию, пока не получилось хоть что-то работающее, или не была потрачена впустую куча времени.
Собственно основная цель данного поста – создать простое приложение, чтобы можно было «пощупать» ESB Toolkit.

Для многих разработчиков программного обеспечения, выбор и изменение модели trial-режима является одной из самых трепетных и обсуждаемых задач. Для одних программ придумать модель проще, для других сложно. А некоторых людей не покидает вопрос: «Мы всё правильно сделали?». Актуальна задача выбора trial-модели и для нас, разработчиков PVS-Studio. Мы решили поделиться некоторыми сопутствующими мыслями и рассказать о том, какой новый вариант мы придумали. Надеемся, что наши рассуждения и некоторые мысли окажутся полезными и другим разработчикам.

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

Мы будем под кэшированием понимать сохранение результатов вычислений в ответ на некоторые запросы. То есть, повторный результат запроса не всегда вычисляется заново, но иногда берется из таблицы, называемой кэшем. Сложно переоценить роль кеширования в современных системах. При этом часто возникает проблема, связанная с недостатком памяти. Действительно, что делать, если запросов много, а памяти хватает лишь для хранения ограниченного числа результатов? В этом случае, как правило, кеш стрится следующим образом. Фиксируется размер кэша, пусть будет N, и сохраняются результаты только для N самых «популярных» запросов.

То есть сохраняются результаты вычислений, которые скорее всего запросят заново.
Как определять эти «популярные» запросы? Наиболее известным способом является LRU, о котором я и расскажу в этой статье.

Computer Scientist, Software Engineer и Coder заходят в бар.
— О, а вот и программисты! — окликает их бармен...

Я знаю людей, которые программируют уже не один десяток лет, но обижаются, когда их называют "программистами". А по запросу Coder vs Developer vs Software Engineer в гугле находится 113 000 000 ссылок: 1 2 3 4 5 6 7 8 9 … 113 000 000. Что интересно, можно найти совершенно противоположные мнения об одном и том же. С чем-то я согласен, а с чем-то в корне нет.

Последние же несколько лет так вообще постоянно подливают масло в огонь, появляются какие-то совсем странные программисты, которые называют себя Creative Technologist, Creative Coder и Interactive Developer.

Давайте же попробуем разобраться.

Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

Если бы вы могли вернуться в прошлое, к самому началу своей карьеры разработчика и сказать самому себе: «прочитай именно эту книгу», в самой начале своей карьеры разработчика, какую бы книгу вы рекомендовали?

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

Введение

Уже не в первый раз мне задают связанные вопросы:
«Зачем ты делаешь так много функций?»;
«Зачем ты выносишь, однократно используемый, код в функции?»;
«Остальные не знакомы с твоими правилами именования функций. Как они будут с этим работать?». Поэтому опишу свое видение проблемы. Ну а сообщество подскажет, к чему же стоит стремиться.

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

Не так давно на работе передо мной была поставлена задача реализовать механизм асинхронного обмена данными между веб-приложением на Java и веб фронт-эндом на стороне клиента. Задача заключалась в том, чтобы клиент получал апдейты с минимальной задержкой, при этом апдейты могли приходить со скоростью 100 апдейтов в секунду, так и 1 апдейд в минуту, т.е. желательно не слать лишних запросов со стороны клиента.

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