Много лет назад я был назначен ответственным за пожарную безопасность в одном офисе IT-компании. Выглядело это так: «Распишись здесь и здесь, всё, твою фамилию на щитке повесим, больше ничего не надо». Проблема была в том, что я нашёл, что же действительно означает такая роспись. И начал «строить» всех в офисе по соблюдению правил безопасности. Если вы не пробовали, сообщаю — зачастую очень сложно делать в обычных условиях. В чём проблема? В том, что большая часть людей считает эту норму условностью. Все нарушают, и мы будем.

Теперь представьте, что вы вводите правило, которому невозможно следовать. Или которому не будут следовать, потому что привыкли делать иначе. И не обеспечиваете жёсткий контроль за каждым случаем. Ну, вроде как форума, где материться по правилам нельзя, но модератору плевать. За примерами чуть покрупнее далеко ходить не надо, но не будем сегодня об этом. Представили?

Знаете, что мы в результате только что сделали внутри компании или отдела? Мы создали ситуацию, в которой виноват каждый человек отдельно, но никто в целом. И это очень важный и жестокий инструмент контроля.

Эта заметка навеяна мелькавшими последнее время на хабре постами двух тематик — «интересные команды unix» и «как я подбирал программиста». И описываемые там команды, конечно, местами интересные, но редко практически полезные, а выясняется, что реально полезным инструментарием мы пользоваться и не умеем.
Небольшое лирическое отступление:
Года три назад меня попросили провести собеседование с претендентами на должность unix-сисадмина. На двух крупнейших на тот момент фриланс-биржах на вакансию откликнулись восемь претендентов, двое из которых входили в ТОП-5 рейтинга этих бирж. Я никогда не требую от админов знания наизусть конфигов и считаю, что нужный софт всегда освоится, если есть желание читать, логика в действиях и умение правильно пользоваться инструментарием системы. Посему для начала претендентам были даны две задачки, примерно такого плана:
— поместить задание в крон, которое будет выполняться в каждый чётный час и в 3 часа;
— распечатать из файла /var/run/dmesg.boot информацию о процессоре.

К моему удивлению никто из претендентов с обоими вопросами не справился. Двое, в принципе, не знали о существовании grep.



Поэтому… Лето… Пятница… Перед шашлыками немного поговорим о grep.

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

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

Возможно, эти события и не были такими удивительными для опытных ИТ-гуру (эка невидаль, когда одна компания покупает 700 инженеров у другой), но для автора, на тот момент управлявшего небольшим отделом о 17 человеках, эти события послужили источником многочисленных наблюдений и выводов о работе с людьми.

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

КДПВ

Вечерело

Мы с товарищем, сделали простенький тест (github) на проверку доступности data-uri в браузерах. Выглядит он следующим образом:



В textarea javascript'ом вставляется navigator.userAgent. В этот момент я не знаю, что меня стукнуло в голову, но вместо DOMContentLoaded, я написал . По-быстрому проверив корректную работу в десктопных браузерах и на нескольких мобильных устройствах, подключённых к интернету через wi-fi, мы успокоились и разошлись по домам.

Солнце продиралось сквозь занавески

Утром, в полупустом вагоне метро, я как всегда открыл браузер на своем телефоне, на котором со вчерашнего вечера была открыта тестовая страничка. Сказать, что я удивился, когда я не увидел вывода userAgent внутри textarea — ничего не сказать.

Добравшись до компьютера, решил потратить немного времени на поиск проблемы. Запустив страничку на десктопе и в эмуляторе, я ничего не заметил. Открыл на телефоне. Чудеса! Всё работает.

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

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

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'demoEnum0' defined in file [...\DemoEnum0.class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [ru.itbasis.demo.spring.enums.DemoEnum0]: No default constructor found; nested exception is java.lang.NoSuchMethodException: ru.itbasis.demo.spring.enums.DemoEnum0.<init>()

(коммит)

В данном посте я попробую обойти это ограничение.

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

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

Тема очень серьёзная. Если гугл заблокирует вас однажды — обратно пути уже не будет. По всей видимости, отслеживается взаимосвязь аккаунта с вашим ФИО, IP, Mac-адресом и прочими личными данными. Испортите отношение с Google один раз — потом не отмоетесь никогда.

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

Исповедь 1

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

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

Примечание от переводчика: если вам позволяет знание английского языка, то я настоятельно рекомендую ознакомиться с оригиналом. Её автор — один из основателей студии Mode 7, которые выпустили Frozen Synapse. Статья очень большая по объёму текста, поэтому, если у вас не получится осилить её за 1 подход, я бы предложил отложить на потом, и продолжить в другой день.

Мне, как разработчику игр, который старается «копать» в этом направлении уже в течении, наверно, 5 лет или больше, и у которого не получилось добиться хоть сколько-нибудь значимого финансового успеха, статья показалась безумно полезной, т.к. вправляет мозги и делится трезвым взглядом на то, как должна функционировать команда или отдельный разработчик в этом жестоком (но, довольно честном) мире разработки игр.

Ниже будет перевод статьи.

От переводчика:
спор сторонников написания final везде и всюду и их противников сродни спору остроконечников и тупоконечников. Как и в некоторых других сообществах, в нашей компании этот вялотекущий спор шел годами. И только эта статья Ричарда Вэрбёртона (Richard Warburton) позволила нашим остроконечникам взять верх.

О чём речь?

Начнем с небольшого рассказа. Несколько недель назад я отправил в список рассылки Java core libs своё предложение убрать модификатор final с некоторых методов. В результате возникло несколько тем для дискуссии. Одна из них, например, — выяснить, в какой степени ухудшится производительность вызова метода, который был final, если этот final с него убрать.

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

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

Перевод второй главы свободно распространяемой книги Building and Testing with Gradle

Задача (task) является основным компонентом процесса сборки в файле билда Gradle. Задачи представляют собой именованные наборы инструкций билда, которые Gradle запускает выполняя сборку приложения. При сравнении с другими билд-системами, задачи могут показаться знакомой абстракцией. Однако Gradle предоставляет более развитую модель, в отличие от той, которая вам уже может быть знакома. По сравнению с традиционными возможностями объявления операций билда, связанных зависимостями, задачи Gradle являются полнофункциональными объектами, которыми вы при желании можете управлять программно.

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

День добрый.

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

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

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

В предыдущей публикации мы рассказали о новом позиционировании нашего продукта, о трансформации его в более комплексное решение Platform-as-Infrastructure, которое сочетает гибкость IaaS и удобство PaaS. В этой статье мы опишем структуру кластера Jelastic и его основные компоненты.

Основная задача Jelastic упрощать сложные технические решения, автоматизировать рутинную работу администраторов и разработчиков. Так, к примеру, уже сегодня вы можете легко развернуть комплексные приложения написанные на Java, PHP и Ruby. Поддержка мультиязчности была изначально заложена в архитектуру Jelastic. В ближайших планах также поддержка Node.js, Python и .Net.

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

Общая информация

Инсталяция Jelastic Platform-as-Infrastructure — это изолированный кластер, состоящий из группы серверов и сервисов, которые взаимодействуют как целостная система, предоставляя возможность удобно разворачивать, тестировать, поддерживать и масштабировать приложения в продакшине.

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

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

Продолжаю начатое, а именно, пытаюсь рассказать (с применением визуальных образов) о том как реализованы некоторые структуры данных в Java.



В прошлый раз мы говорили об ArrayList, сегодня присматриваемся к LinkedList.

LinkedList — реализует интерфейс List. Является представителем двунаправленного списка, где каждый элемент структуры содержит указатели на предыдущий и следующий элементы. Итератор поддерживает обход в обе стороны. Реализует методы получения, удаления и вставки в начало, середину и конец списка. Позволяет добавлять любые элементы в том числе и null.

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

Добрый день, хабровчане. Сегодня я хотел бы рассказать о Location APIs в общем и о геозонах (geofences) в частности, которые были представлены на Google I/0 2013 (видео и презентация). Не смотря на то, что событие произошло более полугода назад, на хабре до сих пор нет вменяемой информации об этом (только одно упоминание). Постараюсь немного исправить ситуацию.

Некоторое время назад я начал рассказывать на Хабре про Elliptics — наше отказоустойчивое распределенное key-value хранилище (к слову, свободное и распространяемое под GPL-лицензией). Тогда я в общем описал устройство Elliptics: про архитектуру и основные принципы работы, за счет чего достигается надежность системы, как систему можно расширять, и как она ведет себя при сбоях.

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



Сегодня — про сетевую и программную архитектуру Elliptics и некоторые из его особенностей. Также я подробно расскажу про кэш и нашу низкоуровневую библиотеку для локального хранения данных — Eblob.

Это четвертая часть, она же заключительная, перевода статьи Пола Грэма, основателя YCombinator — одного из самых успешых стартап акселераторов -, о том, как найти свою идею для стартапа. Первая, вторая и третья части по ссылке.
Так же хочу скромно анонсировать свой небольшой некоммерческий проект — 42Startups.ru,- блог, где вы можете найти другие переведенные с английского языка статьи о стартапах. Лучшие, из тех, что мне попадаются и которые, на мой взгляд, достойны внимания русскоязычной аудитории. Подписывайтесь! А пока продолжим:

Рецепты

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

Остаток эссе я посвящу уловкам, которые помогают найти стартап-идею по требованию.