Несколько вопросов, которые помогут составить общее впечатление о знании языка, к примеру, на собеседовании

Когда я увидел gwt и gwt-ext, я подумал, что меня где-то обманули, когда не рассказали об этом раньше. Мучения с отладкой скриптов с использованием ExtJS были долгими, мы использовали Java как серверную платформу, вручную занимались сериазилацией/десереализацией серверных объектов, подгоняли блоки с помощью css и занимались многими другими вещами, отнимавшими кучу времени. Однако, можно все это оставить позади. Теперь можно рисовать красивые экстовые окошки кодом на Java (not js)! GWT — замечательная вещь. Она позволяет нам уйти от написания js-кода, потому что генерирует js-код самостоятельно; и программист может даже его не смотреть, потому что отлаживать его можно тоже в исходниках на Java!Далее я постараюсь рассказать, как настроить

В продолжении поста "Ресурсы по поиску качественных иконок" представляю свою коллекцию сайтов, на которых вы найдёте очень(!) много качественных наборов иконок. Все сайты проверены руками, следовательно открываются и скачиваются легко.

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

В статье идет речь о методе создания полиморфизма для связей many-to-many в Ruby on Rails.

Задача

Допустим, что необходимо разработать систему управления грузовым транспортом. В нашем распоряжении имеются несколько видов этого транспорта: поезда, вертолеты, грузовики и баржи. И известно, что каждое средство осуществляет перевозку только в строго определенные населенные пункты. Например, часть грузовиков катается по центральной части России, часть по южной, вертолеты работают в Сибири и на Камчатке, поезда вообще ограничены железнодорожным полотном и так далее.
Каждый вид транспорта в разрабатываемой системе будет представлен своим классом: Train, Copter, Truck, Ship соответственно.
Населенные пункты (города, поселки, научные станции, тут нас интересует не размер, а географические координаты), куда осуществляется перевозка, представлены классом Location.
Стоит условие: к каждой единице транспорта может быть привязано сколько угодно Location. В свою очередь к каждому населенному пункту может быть привязано сколько угодно единиц транспорта разных видов.

История

Внедрение Linux в ПриватБанке началось в 2007 году. За это время был пройден большой путь и хотелось бы поделиться с сообществом своим опытом внедрения. На данный момент мы достигли следующих показателей: более 36500 рабочих мест с ОС Linux в 4000 отделений, расположенных в 5 странах.
В 2007 году за основу был взят ASPLinux 11.2. Со временем для альтернативы были выбраны другие дистрибутивы — Fedora, openSUSE, Ubuntu. Позже стала очевидной необходимость создания собственного дистрибутива и системы управления рабочими станциями. Разработка началась в январе 2012 года. Для основы был выбран Ubuntu 12.04 LTS с рабочим окружением Gnome Classic (no effect). Основные аргументы: Ubuntu — самый распространённый десктопный дистрибутив последних лет; обширное комьюнити, где проще найти решение возникающих проблем; именно его в качестве основы внедрения выбрал Google, много примеров внедрения в государственных и муниципальных учреждениях Германии, Франции. Выбор системы управления остановился на Puppet.
В июне 2012 года стартовал переход и к январю 2013 на корпоративную ОС были переведены уже около 95% ПК. Такая скорость перехода обусловлена тем, что сотрудники уже имели опыт работы в Linux.

Основные задачи, которые удалось решить благодаря текущему внедрению:

• cущественная экономия ресурсов при поддержке ОС на рабочих местах сотрудников;
• поддержание программного обеспечения в актуальном состоянии;
• возможность оперативного применения критических обновлений (до 1 часа на всех ПК);
• cбор и анализ статистической информации о парке ПК и периферии;
• создание системы проактивной реакции на сбои (Event Manager).

Дальше более детальное описание компонентов нашей реализации.

По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?

Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

Liquibase — это система управления миграциями базы данных. Это вторая статья о Liquibase, на этот раз содержащая советы «боевого» использования системы. Для получения базовых сведений подойдет первая статья-перевод «Управление миграциями БД с Liquibase» (ссылка).

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

Вот 10 вещей, которые в определенный момент работы с Liquibase были для меня открытием.

1. Версионность приложения должна быть отражена в структуре папок миграций

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

/db-migrations
    /v-1.0
        /2013-03-02--01-initial-schema-import.xml
        /2013-03-02--02-core-data.xml
        /2013-03-04--01-notifications.xml
        /changelog-v.1.0-cumulative.xml
    /v-2.0
        ...
        /changelog-v.2.0-cumulative.xml
    /changelog.xml

Подробнее:

На прошлой неделе Яндекс.Диску исполнился год, и за этот год сервисом успели воспользоваться уже больше 8 000 000 пользователей.

А сейчас мы продолжаем рассказывать о том, сколько усилий понадобилось, чтобы всё это стало возможным. Недавно мы писали о том, как и почему команда Яндекс.Диска выбрала WebDAV для синхронизации десктоп-клиентов с сервером и начала работу над прототипом клиента Яндекс.Диска. Сегодня, как и обещали, — о том, как всё работает с серверной стороны.



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

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

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

В самом Model View Controller шаблоне нет ничего плохого. Он решает ту проблему, для которой его придумали — это разделение логики обработки запроса пользователя и логики представления информации.

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

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

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

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

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

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

Думаю, что большинство программистов, писавших код на JavaScript больше пары дней, сталкивались с этими особенностями. Цель данного топика не открыть что-то новое, а попытаться описать эти особенности «на пальцах» и «недостатки» сделать «преимуществами».

В данном топике будут рассматриваться:

1. Замыкания
2. Прототипирование
3. Контекст выполнения

Не так давно мы начали внедрять Liquibase в качестве инструмента миграций схемы данных в большинстве наших проектов, новых и уже существующих. Система миграций схемы базы данных Liquibase хороша тем, что позволяет использовать системы контроля версий, VCS, (например, Git) для управления ревизиями базы данных приложения. Говоря более точно, VCS содержит описание изменений, необходимые для миграции схемы базы данных из одной ревизии в другую.

Хотя миграция схемы базы данных кажется довольно простой задачей изначально, задача становится сложнее после того, как появляется желание откатывать изменения схемы без ее создания заново.
Кроме схемы и операций DDL, Liquibase позволяет мигрировать данные приложения, с поддержкой наката изменений данных и их отката.

Все данные каталога Active Directory хранятся в БД в файле ntds.dit. Подавляющее большинство приложений взаимодействуют с каталогом через прослойку DSA реализованную в ntdsa.dll. В свою очередь функции из ntdsa.dll не работают напрямую с ntds.dit, их функционал ограничен потребностями службы каталогов и они не могут дать нам представление о внутреннем устройстве БД Active Directory. Тем не менее ntds.dit представляет собой не что иное как БД JET Blue. В каждой версии windows (начиная с Windows 2000) есть всё необходимое для работы с этой БД.

В статье ниже я попробую осветить следующие вопросы:

• Какова структура БД?
• Как данных в ntds.dit получается «дерево»?
• Как реализовано членство в группах?
• Каков формат атрибута replPropertyMetaData и с какой точностью в метаданных репликации хранятся временные метки?

Приветствую вас, хабрачитатели!

Продолжаю попытки визуализировать структуры данных в Java. В предыдущих сериях мы уже ознакомились с ArrayList и LinkedList, сегодня же рассмотрим HashMap.



HashMap — основан на хэш-таблицах, реализует интерфейс Map (что подразумевает хранение данных в виде пар ключ/значение). Ключи и значения могут быть любых типов, в том числе и null. Данная реализация не дает гарантий относительно порядка элементов с течением времени. Разрешение коллизий осуществляется с помощью метода цепочек.

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

1. А сколько займет сделать этот раздел (дается ТЗ из одной строки)?

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

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

2. Ты же ОБЕЩАЛ сделать за два дня, а прошла неделя! (моют мозг по сроку из пункта 1)

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

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

Всем привет!

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

---

Java — это язык с мощными стандартными возможностями, но «Большая сила налагает большую ответственность». Я видел много java-кода, в котором чрезмерно (и зачастую — неправильно) использовались «редкие» свойства языка, в то время как основы основ были почти полностью проигнорированы. Эти наблюдения и послужили стимулом к написанию статьи.

Это не список обязательных к использованию каждым программистом особенностей языка. Скорее наоборот. Я разделил их на 3 группы: "для каждодневного использования", "для периодического использования" и "только для фреймворков и библиотек!". Правило простое: если вы понимаете, что используете указанные свойства чаще, чем рекомендуется, то, скорее всего, ваш код развивается по неправильному пути. Если же наоборот — вы редко используете какие-то свойства, чем я рекомендую, значит вы упускаете какие-то интересные и важные возможности языка.

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

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

Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.

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

Один из ведущих разработчиков Warcraft и Starcraft Патрик Вайат периодически публикует воспоминания о своей работе в компании Blizzard в 90-е годы. Очень интересно посмотреть изнутри на процесс разработки игр, которые стали впоследствии культовыми. В последней заметке Патрик поведал замечательную историю, как пришлось впопыхах исправлять баги в StarCraft перед выпуском игры и что из этого получилось.