Название оригинала: The Well-Grounded Java Developer: Vital techniques of Java 7 and polyglot programming
Автор: Б. Эванс, М. Вербург
Перевод книги: Сивченко Олег
Дата выхода: осень 2013г.

Осенью у нас выходит новая переводная книга по Java. У книги очень хорошие отзывы и высокий рейтинг на сайте www.amazon.com.

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

Уже 2 месяца использую на своих компьютерах модуль zRam и хочу поделиться результатами. На практике он позволил мне не используя раздел подкачки, и не получая видимого замедления работы компьютера увеличить размер оперативной памяти в 2.5-3 раза. На сервере виртуалок тот же подход позволил очень ощутимо увеличить отзывчивость при нехватке памяти.
Заинтересовавшихся прошу под кат.

Месяц назад здесь было объявлено, что Алексей Брагин теперь читает авторский курс лекций об операционных системах. С тех пор Алексей успел провести уже несколько занятий, которые были записаны на видео. Думаю, вполне логичным шагом будет поделиться этими записями с сообществом. Что нам стоит поступить так же как, к примеру, сделал MIT?

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

Переведено в Alconost. Часть 1 — habrahabr.ru/company/alconost/blog/170201

7. Презентуйте и обсуждайте документы, а не слайд-шоу

В интервью Чарли Роузу Безос говорит: «Обычно на корпоративном собрании кто-то один выходит вперед и представляет общему вниманию… что-то вроде слайд-шоу. С нашей точки зрения… таким образом вы получаете очень мало информации, вместо нее вам достаются только тезисы. Это облегчает задачу тому, кто проводит презентацию, но усложняет понимание тем, кто его слушает. Поэтому вместо этого мы на всех наших собраниях рассматриваем подготовленный заранее документ — 6-страничную повествовательную записку. И вот, когда вам приходится выписывать свои идеи в виде законченных предложений и полновесных абзацев, это заставляет вас думать яснее и четче».

Вступление

Как справедливо заметил Fred Brooks, серебряной пули, способной поразить зверя разработки программного обеспечения, не существует. Пока возникают новые требования, идеи и находятся новые баги, программы живут и изменяются. Путь, который проходит код от версии к версии, может быть крайне сложен и извилист. К его созданию причастно много людей: разработчики, тестировщики, бизнес-аналитики, заказчики и т.п. Несмотря на то, что существует много разных видов разработки – аутсорсинг, продуктовая разработка, open-source и т.п., проблемы, стоящие перед командой, остаются примерно одинаковыми. Программное обеспечение – вещь сложная, потребитель хочет получить его как можно быстрее (и дешевле). Качество при этом должно быть приемлемым. Перед командой разработки стоит серьезная задача – наладить эффективное взаимодействие. Одним из самых главных средств коллаборации внутри команды разработчиков является сам код, который они пишут.

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

Самые крутые инструменты — универсальны, с их помощью можно решать самые разнообразные задачи. Примеры таких инструментов — документы и таблицы Google, ментальные карты Mindmeister, доски Realtimeboard. Вы можете их приспособить для чего угодно, особенно таблицы. Придумать и сделать такой инструмент сложнее всего. Я расскажу о еще одном универсальном инструменте, который мы активно используем — Tom's Planner.

Переведено в Alconost.

Если сегодня спросить у начинающих предпринимателей на кого они равняются, прозвучат привычные имена: Стив Джобс, Элон Маск, Марк Цукерберг, некоторые вспомнят еще Билла Гейтса. Но, к сожалению, немногие назовут Джеффа Безоса — основателя и генерального директора Amazon.

Суть проблемы

Сейчас появляется очень много материала про юнит и нагрузочное тестирования. Все поголовно пишут тесты, код создают исключительно через TDD, используют jmeter/ab. Однако, все тестирование очень тесно связано с тестовыми данными. А их нужно генерировать/писать. Проблема не стоит остро для юнит тестирования — накидал mock, погонял его и забыл. Но как быть с нагрузочным тестированием? Когда мне нужно не 1-2-5-10 объектов, а миллионы?

Большинство (php) разработчиков, которых я встречал, сталкиваясь с задачей нагрузочного тестирования своего кода, создают несколько фикстур руками и насилуют их (ab/jmeter). Полученный результат тестирования не является достоверным, но они об этом не думают. Более продвинутые пишут скрипты для генерации данных, закидывают в БД и после этого уже играются. Похвально, но таких значительно меньше, а сам способ мне не кажется идеальным — другой программист может не разобраться в говнокоде генерилки фикстур (ведь создатель писал это быстро и для утилитарных целей) и рано или поздно все либо пойдут по первому пути, либо начнут писать новую генерилку.

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

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

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

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

Попробуем закрыть этот пробел.

Кратко обозначены, выделены и пояснены основные, наиболее важные моменты.

UPD. Пост про менеджмент, а не про менеджеров.

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

Различные реализации игры «Жизнь» описывались на Хабре уже неоднократно. В этой статье, в качестве продолжения этой темы, рассматривается ещё один её вариант: в качестве игрового поля используется регулярная решётка на плоскости Лобаческого. Описываются общие методы использования плоскости Лобачевского в программах и необходимые для этого математические приёмы.
Как возникла плоскость Лобачевского, достаточно известно. В позапрошлом веке господа Гаусс, Лобачевский и Бойяи, проживавшие примерно в одно время в разных странах тогдашней Европы, задумались, что будет, если отменить пятый постулат Евклида и заменить его на противоположную аксиому. Оказалось, что не случится ничего плохого, и никаких противоречий не возникнет. Заметная часть последующего изучения неевклидовой геометрии была посвящена выяснению того, кто из них у кого украл идею этой самой геометрии.
Менее известно, что несмотря на «отрицательный» способ определения неевклидовой геометрии (вместо того, чтобы сказать, что через точку проходит ровно одна прямая, не пересекающая данную, мы говорим, что таких прямых может быть сколько угодно), мы, тем не менее, получаем систему теорем и формул, не менее стройную, чем та, что есть в евклидовой геометрии. И одновременно, у нас есть гораздо большее разнообразие геометрических фигур, в том числе, разбиений плоскости на правильные многоугольники.

Не так давно Стивен Синофски (экс-вице-президент подразделения Windows в Microsoft) начал вести свой блог, в котором он делится мыслями о продуктах, продуктовой разработке и управлении.
Мы с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.

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

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

Естественное напряжение (sic!)

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

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

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

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

Вот, к примеру, что советует президент Microsoft в России для борьбы с нехваткой времени:

• Планируйте график таким образом, чтобы решать как можно меньше второстепенных срочных задач, а важные — решать до того, как они станут срочными;
• Занимайтесь любимым делом с максимальной вовлечённостью;
• Рассматривайте принцип жизненного баланса как важную личную и менеджерскую задачу.

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

Творческая беседа Дэна Шиппера, кофаундера Firefly и Джейсона Фрайда, кофаундера 37signals привела автора статьи к занятным выводам о том, как и кому продавать ПО. Надеемся, и вам, Хабражители, принесет пользу.

Переведено компанией-локализатором Alconost

Это перевод нашумевшей статьи с TechCrunch от Джеймса Альтушера — инвестора, программиста, автора статей и немного предпринимателя. Его последние книги: Я был слеп, но теперь я вижу и 40 альтернатив колледжу. Читайте его в Twitter @jaltucher.

Люди читают TechCrunch потому, что они хотят что-то создать, они не желают следовать приказам всю жизнь и хотят финансовой свободы. Давайте начистоту. Эти три пункта кажутся притягательными. Да благословит Вас Бог. Надеюсь, что когда Вы их обретете, Вы сможете сохранить их. Большинству людей (например, МНЕ), нужно просто немного покататься на американских горках, потому что мы тупые. Но некоторые люди умные.

Думаю многим хабровчанам знакома книга «Этюды для программистов» Чарльза Уэзерелла. Если нет, то здесь можно прочитать интервью с автором и небольшой обзор книги. Мне самому совсем недавно попала данная вещь в руки, и было решено обязательно реализовать одну из задачек.

Итак предлагаю разобрать с вами один из этюдов. Писать будем на Java, поработаем с графикой и GUI + разберем алгоритм перебора с возвратом для нахождения нашего решения. Маловероятно, что статья заинтересует профи, но вот новичкам, а особенно тем, кто только изучает Java, статья может оказаться полезной.
Всем заинтересовавшимся – добро пожаловать!

Привет, Хабр!

К нам в Alconost часто приходят клиенты и говорят “Мне нужна справочная система для моей программы. Сделайте мне ПэДээФку”. Мы создаем руководство пользователя, оформляем PDF, а потом оказывается, что на самом деле нужна была контекстная справка с индексом и поиском.

Именно поэтому хотелось бы поделиться со всеми простыми схемами и описанием видов и форматов справки.

В последней в уходящем году публикации в нашем корпоративном блоге мы хотим подвести некоторые итоги и представить рейтинг лучших профессиональных книг, выпущенных «Питером» в 2012 году.

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

Представляем книжный топ-18 от «Питера»: от UI и .NET до теории струн!

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

1. Parted Magic OS: дистрибутив для восстановления дисков и работы с разделами, который поддерживает более десяти файловых систем и включает различные утилиты для «переноса, копирования, создания, удаления, расширения и сжатия дисковых разделов. Клонирование дисков и осуществление полного бэкапа. Тестирование дисков на возможность сбоя в будущем. Поиск сбойных секторов. Тестирование производительности компьютера. Безопасная полная очистка диска без возможности восстановления. Доступ к незагружаемым HDD для восстановления важных данных».