С выходом седьмой версии JDK нам, счастливым разработчикам на Java, стал доступен из коробки фреймворк Fork/Join, о котором уже писали на хабре тут. Фреймворк в плане API очень похож на уже привычный ExecutorServices, но даёт весьма ощутимый прирост производительности и действительную «легковесность» потоков.

Здесь, я бы хотел рассмотреть на что стоит обратить внимание при переходе на Fork/Join.

Сегодня попробую осветить денежные вопросы.
Банковский счет, карты, платежи, PayPal и все такое.
Это продолжение топика HOWTO: свой бизнес в США из России, если кто пропустил.

В ближайшем будущем нас ожидают новые большие изменения. Техника открывает нам и сулит нам невиданные перемены, неслыханные возможности. Но надо, чтобы ко всем этим переменам и возможностям мы были готовы.
Я. В. Соколов (д. э. н., профессор, член Методологического совета по бухгалтерскому учету при Минфине России)

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

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

Я юрист ИТ-компании, которая занимается разработкой мобильных приложений и базируется в СНГ, и по роду своей деятельности тесно связан с процессом подписания контрактов с Заказчиками, которые в последнее время все чаще и чаще норовят не согласиться с условиями нашего «шаблонного контракта». Вот и теперь очередной британский Заказчик требует пересмотра состава гарантийных обязательств, которые мы обычно предлагаем. Для удобства заказчика применимым правом выбрано английское право, что подразумевает определенные трудности при согласовании таких сложных условий как гарантии.

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

Сперва возникает желание дать все гарантии Заказчику, и тем самым сохранить хорошего клиента и дружеские отношения с менеджером. Наша команда работает качественно и в срок, и проблемы с Заказчиками возникают в основном по косметическим моментам. Но значит ли это, что мы готовы на неограниченные гарантии?

Уверен, что не готовы ни мы, ни любая иная отечественная компания-разработчик. И если основная задача юриста – это распознать и нивелировать правовые риски, то мне бы стоило задуматься над тем, какие гарантии мы можем предложить Заказчику, а какие оставить за бортом.
Проведя небольшое исследование, хочу поделиться своими выводами по этому поводу:

Разработкой браузерных GUI под явой я занимаюсь уже около 12 лет, среди прочего имею опыт использования сервлетов, JSP, XML/XSLT, Struts, Tapestry (3,4,5), Wicket, Spring MVC и GWT.

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

Время шло, JSF не собирался умирать, а появился уже в версии 2.1. И я решил попробовать использовать его для одного из своих экспериментальных проектов, на которые я трачу примерно 3 месяца каждый год — для расширения кругозора и отвлечения от скучного консалтинга (которым зарабатываю детишкам на молочишко в остальные 9 месяцев).

Год назад я прочитал книгу Getting Real от 37signals. Она очень впечатлила меня, и я решил, что стоит опробовать этот подход в нашей компании, чем и занялся прямо с начала 2011 года. Эта статья — своего рода отчет о годовом опыте внедрения Getting Real в отдельно взятой компании. Отчет конечно же промежуточный, потому что о реальном эффекте от изменения подхода к работе (а Getting Real – это не методика управления или разработки, а именно подход) можно судить спустя более ощутимый промежуток времени; к тому же, не все принципы подхода мы смогли применить. Об этом я тоже расскажу.

Я считаю, что каждый программист должен написать свой компилятор.

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

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

«Первое правило бизнеса – защищай свои инвестиции»
этикет банкира 1775 г.

Если в те времена инвестиции защищались с оружием в руках, то в современном мире таким оружием становятся информационные технологии.

Десять лет назад у меня было несколько бизнес-единиц. Я представлял себя в будущем, сидящим перед десятком мониторов, на которых отражается информация о состоянии десятков, сотен бизнесов, принадлежащих мне. Тогда я искренне верил, что это возможно (нажал одну кнопку и все понятно). Но чем больше становилось у меня бизнесов, тем меньше я их контролировал. И тем больше терял.
Основной причиной всех потерь был плохой контроль бизнеса. Тогда встал вопрос:

Как можно контролировать бизнес настолько хорошо, чтобы обезопасить себя от потерь?

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

Сегодня я готов поделиться с читателями хабра некоторыми своими знаниями.

Предлагаю краткий обзор свежего UI-фреймворка от Telerik под названием Kendo UI.

Предыстория

Совсем недавно я размещал тикет в поддержке Telerik и спрашивал у них, можно ли использовать компоненты (в частности MVC) в приложении, написанном на Classic ASP.

Конечно, ответ огорчил.

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

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

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

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

Безусловно в этом списке вы обязательно найдёте уже знакомые расширения, однако огромный пласт полезных расширений всегда остаётся в стороне. Так что приготовьтесь установить ещё парочку расширений! :)

Встроенные инструменты разработки в Firefox

Перед началом списка было бы неправильно не упомянуть об инструментах, уже встроенных в Firefox. Здесь речь идёт о тех самых инструментах разработки в Firefox Aurora 10 и том функционале, который сегодня можно найти в любом современном браузере.

При разработке интерфейса этих инструментов было перепробовано множество подходов и решений. В результате получился довольно приятный интерфейс, который любой желающий может испробовать, установив Firefox Aurora (хм, вы ещё его не поставили?)



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

Представляю вашему вниманию перевод статьи под названием "Site Search: Strategies for No Results Found" от Linda Bustos. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением компании Elastic Path.

Эта статья написана по мотивам книги Грега Ньюдельмана "Designing Search: UX Strategies for Ecommerce Success". Необычно видеть книгу на 300 страниц, посвященную одному единственному аспекту создания интернет-магазинов, но оптимизация поиска по сайту действительно заслуживает такого внимания!



Есть одна составляющая оптимизации поиска по сайту, на которой мы часто зацикливаемся: как удержать пользователя на сайте, даже если в результате поиска ему не удалось найти то, что требовалось. Статья основана на разделе "No Search Results Strategy: Not a Zero-Sum Game" вышеупомянутой книги. Ньюдельман говорит о том, что «нет простого набора правил, которые гарантировали бы успешное внедрение страницы результатов поиска в случае, когда не было найдено ни одного совпадения. Но есть четыре принципа, от которых стоит отталкиваться»:

Недавно в Google Maps API V3 появилась новая библиотека Drawing. Она предоставляет набор инструментов, с помощью которых пользователи могут ставить маркеры, рисовать на карте линии, круги, прямоугольники, многоугольники, чтобы выделить различные места на карте.



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

Всё началось год назад, когда я купил свой первый нетбук acer aspire one d255 c процессором Intel Atom N450 и жужжащим кулером в комплекте. Тогда я ещё не задумывался о системе охлаждения и думал, что без вентилятора, гоняющего воздух, было не обойтись.

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

Всё что Вам нужно – это пара старых очков, нож для бумаги и растворитель для краски.

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

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

Timsort, в отличии от всяких там «пузырьков» и «вставок», штука относительно новая — изобретен был в 2002 году Тимом Петерсом (в честь него и назван). С тех пор он уже стал стандартным алгоритмом сортировки в Python, OpenJDK 7 и Android JDK 1.5. А чтобы понять почему — достаточно взглянуть на вот эту табличку из Википедии.



Среди, на первый взгляд, огромного выбора в таблице есть всего 7 адекватных алгоритмов (со сложностью O(n logn) в среднем и худшем случае), среди которых только 2 могут похвастаться стабильностью и сложностью O(n) в лучшем случае. Один из этих двух — это давно и хорошо всем известная «Сортировка с помощью двоичного дерева». А вот второй как-раз таки Timsort.

Алгоритм построен на той идее, что в реальном мире сортируемый массив данных часто содержат в себе упорядоченные (не важно, по возрастанию или по убыванию) подмассивы. Это и вправду часто так. На таких данных Timsort рвёт в клочья все остальные алгоритмы.

Update (22.07.2013)

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

Вместо вступления

Если кто не знает, Go (www.golang.org) – компилируемый язык программирования. Как и все хочет быть «лучше чем C». Разработку языка поддерживает Google (создатели языка — Rob Pike, Robert Griesemer и Ken Tompson), но Go — полностью open-source, в разработке принимает участие большое количество людей не из Google. Меня язык заинтересовал своей простотой и необычным подходом к ООП и многопоточности. Захотелось попробовать. Моя рабочая OS — Windows и будучи разбалованным платформой .Net, C# и Visual Studio мне было трудно именно начать. Хотя на самом деле это оказалось совсем просто, и достаточно быстро я настроил себе удобный Environment, состоящий, по сути, из IDE с подобием IntelliSense. О том, как это сделать за 15 минут я и хотел бы рассказать.