Доброго времени суток уважаемые хабравчане. Как-то мне пришлось писать небольшой проект, так как у меня была возможность свободного выбора технологий я решил использовать Spring Framework. Сразу же хочу сказать я не являюсь гуру в данном фреймворке, и буду благодарен правкам.

Немного поискав на хабре, я не смог найти именно того о чем хочу вам сейчас рассказать и продемонстрировать. Поэтому решил написать пост на данную тему. Речь пойдет о JavaConfig, а именно о том как сконфигурировать Spring MVC проект не используя *.xml конфигурации, например: (mvc-dispatcher-servlet.xml).

Привет всем!

В этом материале мы постараемся написать приложение защищенное Spring Security с применением Java Config (подхода на основе использования аннотаций и классов для настройки контекста Spring приложения) вместо XML.

Используемые Технологии

• Spring 4.0.5 Release
• Spring Boot 1.0.1
• Spring Security 3.2.3 Release
• Maven
• Tomcat 8
• Servlet Api 3.1
• Java 1.8

Это будет очень простое веб приложение, Hello World на базе Spring MVC и Spring Security. Все настройки мы осуществим используя только Java классы, без единой строчки конфигурации в XML.

Доброе время суток, граждане хабражители! Сегодня открылся для сторонних разработчиков новый open-source проект, кроссплатформенный двухпанельный файловый менеджер. Начну данную статью, пожалуй, с предыстории. Для Windows существует всем известный файловый менеджер Total Commander, выгодно отличающийся от других богатым функционалом, мощной системой плагинов, основанной на Win32 API, глубокой настройкой и многооконным режимом. Для других ОС сравнимых по высоте функционала файловых менеджеров пока не существует. А те, что существуют либо давно не развиваются, либо не поддерживают плагины. И всё было нормально, да однажды я решил почистить свой Debian от накопившегося хлама. Процесс чистки стал представлять собой кучу окон и вкладок терминала с Midnight Commander, кучу вкладок и окон различных редакторов и просмотрщиков, графическая оболочка к архиваторам FileRoller и т.д… «Не дело» — решил я, и 24/06/2013 начал изобретать велосипед сделал git init и запустил MonoDevelop…

Так появился новый некоммерческий стартап, ещё один двухпанельный файловый менеджер, правда, в отличие от большинства, кроссплатформенный. Его название долго выбиралось, однако решил остановиться на File Commander (не путать с заброшенным FileCommander). Простое, понятное название, по аббревиатуре не путающееся с другими * Commander’ами. Он написан на C# с использованием тулкита XWT, о котором на Хабре писалось ранее. Использование .Net/Mono и XWT обеспечивает полноценную кроссплатформенность (Windows, Linux, Mac OS). Собственно, ключевой фишкой FC является не столько оригинальная функциональность, сколько независимость его и всех плагинов от используемой операционной системы.

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

Думаю все заметили, что сейчас стало появляться множество всяких бродилок с выживанием в стиле Minecraft. Сделать такую решился и я. Начало было лёгким — Unity3d имеет огромный функционал для сознания простеньких игр (и не только). Персонаж, игровые объекты, в общем основу сделать быстро. Но какой minecraft без рандомно генерируемого мира? Это стало первой трудной задачей. И думаю не только для меня. Просмотрев весь гугл и потратив кучу времени на эту бесполезную вещь я решил написать эту статью дабы сократить страдания других.

Всем привет! В этом посте хотел бы поделиться опытом создания и развития сервиса для одной небезызвестной онлайн игры.

Жизнь в нем еще пока теплится, но, думаю, уже можно подвести окончательные итоги.

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

Предпосылки к переменам

Новость о выходе ASP.NET vNext в сети распространилась достаточно быстро вместе с анонсом наиболее интересных новшеств, предложенных в обновлении. ASP.NET MVC 6 получил новое имя и позиционируется как что-то действительно новое в среде web фреймворков Microsoft (MS).

Оригинальная версия старинной французской поговорки гласит: Le bon Dieu est dans le détail («Бог в деталях»). Собственно, неприметные на первый взгляд детали и отличают Sketch от многочисленных конкурентов. Давайте поближе взглянем на этот кладезь удивительных мелочей.

Решил собрать сервисы, которые могут быть полезны веб-разработчикам и дизайнерам. Буду рад, если кто-то найдет для себя полезный сервис. Осторожно, под катом куча картинок!

Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.

Одним из самых главных изменений является поведение команды git push. Теперь по умолчанию (если не указана ветка) push будет осуществлен только в текущую ветку. Git 1.* по умолчанию делал push во все ветки, которые были изменены локально. Конечно же можно вернуться к прежнему поведению, для этого служит опция push.default.

Поведение Git 1.*:

git config --global push.default matching

Новое поведение по умолчанию в Git 2.0:

git config --global push.default simple

Другие изменения:

На Хабре уже есть статьи по созданию нагрузочного проекта в Visual Studio. В этом посте хочу рассказать о практической стороне тестирования: какую инфраструктуру мы используем для запуска нагрузки, как делаем замеры производительности, что делаем с полученными данными. Подробные пошаговые инструкции по подготовке проекта и настройке в Visual Studio есть и на MSDN, поэтому не буду заострять на этом внимание, отмечу лишь важные, на мой взгляд, моменты. Поскольку разработка в организации основана на стеке технологий Microsoft, то и для тестирования мы решили использовать возможности Visual Studio, а именно модуль MS Visual Studio Load Testing, который доступен в Ultimate версии VS.

Каждый программист — проектировщик API. Хорошие программы состоят из модулей, а протокол взаимодействия модулей — это тоже API. Хорошие модули используются повторно.

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

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

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

Дисклеймер: если после прочтения этого текста вы захотите внедрить KPI для программистов — сходите прочитать еще и это.

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

Итак, какие цели преследует аттестация.

В наших с вами интернетах недавно поднялся нешуточный шум по поводу того, жив ли TDD сейчас, нужен ли он, и в каком виде. Все началось со статьи Дэвида Хансона «TDD is dead. Long living testing», после которой последовали статьи многих авторов и живые обсуждения этой проблемы включая hangout вместе с Дэвидом, Кентом Беком и Мартином Фаулером (кстати, очередной hangout будет завтра, 16 мая).

Но немногие знают, что за несколько дней до этого все тот же Мартин Фаулер постарался дать определение модульного теста (bliki:UnitTest), перевод которого представлен ниже. А после перевода идут кое-какие мои мысли по этому поводу.

В нашей небольшой компании (6 backend + 4 frontend разработчика) для code review (далее CR) мы использовали Gerrit. Gerrit используется, например, для разработки Android. Это инструмент, дающий очень много свободы в настройке процесса CR, но мы от него отказались. Почему? Он прекрасен для суровых backend парней, который легко делают interactive rebase, merge, resolve conflict, amend commit и т.д. Люди из frontend команды по ночам плачут в подушку от тягот рабочего процесса в Gerrit.

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

Мы пришли к Bitbucket. Под катом ответы на вопросы почему Bitbucket и почему не GitHub.

Примечание: Данный пост написан британским разработчиком и финансовым аналитиком Майклом Халлс-Муром, который является профессионалом в так называемом Quantitative trading. С нашей точки зрения информация, содержащаяся в этом топике, может быть интересна техническим специалистам и разработчикам, которые интересуются фондовым рынком и обладают навыками для создания, к примеру, успешных торговых роботов, но не знают с чего начать. Поэтому топик будет рассматриваться именно в таком контексте, кроме того, текст адаптирован к российским реалиям, соответственным образом переведены и некоторые термины. Будем рады вашим комментариям! (Поправки по переводу лучше отправлять в личных сообщениях).

Алгоритмическая торговля — является крайне сложной областью финансов, и чтобы освоить объем информации, который позволит создать свою собственную торговую систему или устроиться разработчиком в финансовую компанию или фонд, потребуется довольного много времени. Большой опыт в программировании просто необходим для успешной работы на этом рынке, как минимум алготорговец должен хорошо разбираться в таких языках, как C/C++ (в области финансов перспективен и язык Java) и Python, Matlab и R (на российском рынке набирает популярность разработанный в США TradeScript — прим. перев.).

История

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

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

И наконец, в один прекрасный день вы решили: “Сделаем это!”. И вот вы уже пытаетесь разобраться как реализовать бизнес-логику своего приложения, ту киллер-фичу, которая будет двигать продукт вперед. У вас есть идея как это сделать, и вы знаете, что способны на это. И вот вы говорите: “Готово! Работает!” У вас есть успешный прототип! Осталось только упаковать его в веб приложение.

“Окей, сделаем сайт,” говорите вы.

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

Перед вами десятки и десятки архитектурных решений, которые необходимо принять. И вы не хотите ошибиться: требуются технологии, которые позволят вести быструю разработку, поддерживают постоянные итерации, максимальную эффективность, скорость, устойчивость и многое другое. Вы хотите быть бережливым (lean) и гибким (agile). Вы хотите использовать технологии, которые помогут вам быть успешным как в краткосрочной, так и в долгосрочной перспективе. А выбрать их далеко не всегда так просто.

“Я перегружен”, говорите вы и чувствуете себя перегруженным. Энергия уже не та, что была в начале. Вы пытаетесь собраться с мыслями, но работы слишком много. Прототип медленно блекнет и умирает.

Похоже, что Etherent и TCP/IP — все ещё самый распространенных способ связи самых разных устройств. Хотя WiFi в последнее время потихоньку вытесняет проводной «медный» Etherent, тем не менее, найти порт и «воткнуться в локалку» — до сих пор самый простой способ подключения. Такая доступность Ethernet не обошла стороной и самые маленькие железки: контроллеры, датчики, счетчики потребления и т.д. которые нынче называются модным маркетинговым словом "Интернет вещей*" (Internet Of Things, IoT).



И тут нам могут здорово помочь корейские микросхемки от WIZnet. Компания WIZnet — это довольно активный производитель чипов класса IOcP (Internet Offload co-Processor). Что это? Говоря человеческим языком — это такой чип, который: с одной стороны имеет Etherent, внутри содержит собственный крошечный процессор для обработки TCP/IP, а с другой стороны — простой интерфейс для связи с нашей маленькой железкой.

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

Осмелюсь описать бюджетный вариант, который в базовом функционале не уступает вышеописанным продуктам. А с точки зрения управления может быть более гибок.
В проекте используется 15 медиасерверов (Windows 7), с каждого из которых идёт свой видеоряд отображаемый на плазмах и проекторах, а также аудиопоток, сопровождающий видеоряд. Также имеется 3 акустические системы, на которые аудиопоток можно вывести.

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

Лучше поздно, чем никогда. Я наконец понял свою ошибку, и теперь начну с того, с чего обычно начинаются все книги — с оглавления.
Структурное представление умного дома:

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