Добрый день, уважаемые коллеги. В этой статье я бы хотел рассказать о своем аналитическом понимании различий паттернов MVC, MVP и MVVM. Написать эту статью меня побудило желание разобраться в современных подходах при разработке крупного программного обеспечения и соответствующих архитектурных особенностях. На текущем этапе своей карьерной лестницы я не являюсь непосредственным разработчиком, поэтому статья может содержать ошибки, неточности и недопонимание. Заинтригованы, как аналитики видят, что делают программисты и архитекторы? Тогда добро пожаловать под кат.

Молодой программист, едва закончивший или ещё даже не закончивший ВУЗ, готов свернуть горы, учиться, учиться и ещё раз учиться и ему близлежащее будущее кажется таким:



Но более опытные товарищи знают, что на самом деле на его пути давно уже заботливо разложены грабли и путь от Junior'а к Senior'у выглядит как-то так:



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

После публикации топика о Maven в комментариях возникли вопросы о том, как начать с ним работать, с чего начать, как составлять файлы pom.xml, откуда брать плагины и т.п. Данный топик будет своего рода getting started или f.a.q.

Из опыта code-review и ответов на StackOverflow набралось немало моментов, касающихся Java Collections API, которые мне казались очевидными, но другие разработчики о них почему-то не знали или знали, но не чувствовали уверенности их применять. В этой статье я собираю в общую кучу всё, что накопилось.

Содержание:

1. List.subList
2. PriorityQueue
3. EnumSet и EnumMap
4. Set.add(E) и Set.remove(E) возвращают булево значение
5. Map.put(K, V), Map.remove(K), List.set(idx, E), List.remove(idx) возвращают предыдущий элемент
6. Map.keySet() и Map.values()
7. Arrays.asList может быть ключом
8. Collections.max
9. LinkedList, Stack, Vector, Hashtable

От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

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

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

Про монаду ходит множество мемов и легенд. Говорят, что каждый уважающий себя программист в ходе своего функционального возмужания должен написать хотя бы один туториал про монаду — недаром на сайте языка Haskell даже ведётся специальный таймлайн для всех отважных попыток приручить этого таинственного зверя. Бывалые разработчики поговаривают также и о проклятии монад — мол, каждый, кто постигнет суть этого чудовища, начисто теряет способность кому-либо увиденное объяснить. Одни для этого вооружаются теорией категорий, другие надевают космические костюмы, но, видимо, единого способа подобраться к монадам не существует, иначе каждый программист не выдумывал бы свой собственный.

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

Именно поэтому важно если не постичь глубинную суть этого паттерна, то хотя бы научиться распознавать примеры использования монады в уже существующих, окружающих нас API. Конкретный пример всегда даёт больше, чем тысяча абстракций или сравнений. Именно такому подходу и посвящена эта статья. В ней не будет теории категорий, да и вообще какой-либо теории. Не будет оторванных от кода сравнений с объектами реального мира. Я просто приведу несколько примеров того, как монады уже используются в знакомом нам API, и постараюсь дать читателям возможность уловить основные признаки этого паттерна. В основном в статье пойдёт речь о Java, и ближе к концу, чтобы вырваться из мира legacy-ограничений, мы немного коснёмся Scala.

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

Далее следует попытка выделить набор особенностей стандартного Common Lisp, кратко и с примерами.

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

Текст по большому счёту основан на списке особенностей CL и обзоре CL Роберта Стренда (Robert Strandh).

Итак, вы работаете на Java с самого её появления? Вы помните те дни, когда она называлась «Oak», когда про ООП говорили на каждом углу, когда сиплюсплюсники думали, что у Java нет шансов, а апплеты считались крутой штукой?

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

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

Собственно через регулярные выражения я к ним и пришёл.

Это заметка о проблеме, с которой я столкнулся в процессе перевода проекта с Java 7 на Java 8. Случилось это уже около полугода назад, но написать решил сейчас, потому что неожиданно про нее(проблему) вспомнил.

Итак, с места в карьер.

Не прошло и года, как я добрался до продолжения статьи про асинхронность. Эта статья развивает идеи той, самой первой статьи про асинхронность [1]. В ней обсуждается достаточно сложная задача, на примере которой будет раскрыта мощь и гибкость использования сопрограмм в различных нетривиальных сценариях. В заключение будут рассмотрены две задачи на состояние гонки (race-condition), а также небольшой, но очень приятный бонус.

Введение

Бывают ситуации, когда очень хочется использовать любимый редактор, но под рукой нету *nix операционных систем, либо разработка ведётся на Windows.

Первое что приходит на ум — использование Windows версии gVim, но в этом случае возникает куча проблем с установкой плагинов, переносом конфигов и адаптации всего и вся. Что-то не будет компилироваться без бубна (например Ctrl-p), а что-то падать во время работы.

Прошлой осенью, вернувшись из отпуска, я обнаружил, что Дехана, наш Product Manager в UserVoice, заменила мой любимый «Roadmap» в Google Docs на доску Trello.

Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом Trello, а в том, как мы им пользовались. Trello – это ОЧЕНЬ открытый проект. Не существует единственного “правильного” способа работы в Trello, поэтому, чтобы чувствовать себя в нем как дома, вам потребуется время для настройки «под себя».

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

У меня давно была идея реализовать что-нибудь интересное, связанное с квайнами. И наконец-то получилось довести это дело до конца. Когда-то увидел реализацию игры «Жизнь» в исходном коде: Self Printing Game of Life и мне захотелось сделать нечто похожее. Некоторое время поразмыслив, я вспомнил, что существует ASCII-графика. Но еще интересней и сложнее было бы сделать анимацию в ASCII-графике. Пример долго искать не пришлось, почти сразу же были найдена анимация «Звездных войн», а точнее 4 эпизода «Новая Надежда» под названием Asciimation. Работа японского программиста Yusuke Endoh «квайновая эстафета» также подстегнула меня к реализации этой идеи. В процесс реализации такого «фильма» пришлось решить множество других проблем, о чем, впрочем, жалеть не пришлось.

Получившийся исходник вот: gist. Для облегчения «просмотра» там также содержится скрипт, который и будет крутить всю анимацию. Исходники же всего проекта для его генерации, интерфейса и других утилит выложены на гитхабе: Freaky-Sources (Туда же включены квайны-палиндромы, о которых я уже писал). Понятное дело, что подобная вещь не несет в себе никакой практической пользы, это просто just for fun.

Это Norton Commander? Это Volkov Commander? Это Dos Navigator? Это Far Manager?
Нет, это «Деодар» — новая рабочая среда для Линукс.
Деодар хостится на GitHub, основан на Node.js, написан на JavaScript плюс немного C++.
Распространяется по антилицензии Unlicense.org. Безвозмездно, то есть даром.
В данной статье на большом количестве картинок и малом количестве пояснений вы можете ознакомится с тем, что уже есть.
Да, «Деодар» — это такое дерево, Cedrus Deodara растёт высоко в горах, очень красивое.

Доброго времени суток. Это статья — перевод заинтересовавшего меня поста в блоге аспиранта Университета штата Нью-Йорк в Стоуни-Брук. Статья в доступной форме описывает основные концепции функционального программирования, их преимущества и недостатки. Думаю она будет полезна широкому кругу читателей, которые сомневаются, нужно ли им углубляться в мир функционального программирования или нет. Пожелания, предложения и замечания по переводу и терминологии принимаются по личной почте.

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

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

Здравствуйте.
Меня зовут Кислин Григорий. В начале ноября в Санкт-Петербурге закончился первый обучающий семинар «Java. Базовый курс», сейчас переименнованый в «Java. Junior Developer. Интенсив». Хочу поделиться с Вами полученным при его проведении опытом на тему обучения Java а также своим опытом трудоустройства на позицию Java разработчика.

Приветствую вас, уважаемые Хабравчане!

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

Minecraft

Наш проект (в начале нас было только двое: я и Feyola) начинался как сервер Minecraft для друзей. То есть, скорее для друзей друзей друзей, потому что с друзьями мы играли и раньше, но в этот раз решили запуститься уже на более-менее постоянной основе и не сильно фильтровать приходящих людей. Запуск наметили на 1 ноября 2010 года, приурочив его к выходу Minecraft Halloween Update, который принёс в Minecraft много нового. Мы расстались с нашим старым миром и начали всё заново, серьёзно и даже без админских команд.

Мне со школьных времен был интересен алгоритм вывода аналитических производных и упрощения выражений. Данная задача была актуальна впоследствии и в вузе. Тогда-то я реализовал ее, только получилось все не так, как хотелось: вместо кода IL у меня просто генерировался C# код в текстовом виде, сборки не выгружались, ну и к тому же не было возможности вывода производных в аналитическом виде. Однако потом я решил все-таки реализовать такую библиотеку, так как интерес остался. Стоит отметить, что таких библиотек в интернете большое количество, но нигде я не нашел именно этапа компиляции выражений в IL код, т.е. по сути везде выполняется интерпретация, которая не столь эффективна, в отличие от компиляции. Ну и к тому же я это разрабатывал чисто для себя, для изучения новых технологий, особо не надеясь, что результат моих трудов может где-нибудь потребоваться. Для нетерпеливых: исходники, программа.

Используемые программы и библиотеки

1. GOLD Parsing System — IDE для написания грамматик и генерации кода лексеров и парсеров под различные языки (C, C#, Java, JavaScript, Objective-C, Perl, Python, Ruby и др.). Основана на LALR парсинге.
2. Visual Studio 2010
3. GOLD.Engine — сборка под .NET, подключаемая для взаимодействия со сгенерированными таблицами.
4. NUnit — Открытая среда юнит-тестирования приложений для .NET.
5. ILSpy — OpenSource дизассемблер под .NET.

Этапы, на которые я разбил весь процесс:

1. Построение дерева выражения
2. Вычисление аналитической производной
3. Упрощение (симплификация) выражения
4. Обработка рациональных дробей
5. Компиляция выражения

Этот пост – отчет по результатам годового изучения платформы Java EE.
Он будет полезен мне своей отчетностью. Может быть пост будет полезен тем читателям хабра, которые задумали учить Джаву.