Эффект Glitch Лукаса Беббера выглядит очень круто — как будто вы смотрите на текст на старом мониторе, который слишком часто роняли на пол и у него «плавает» вертикальная синхронизация и сведение.

Реализация этого эффекта на CSS выглядит вполне убедительно. Мне пришлось немного поломать голову, чтобы выяснить, как он работает, и теперь я хочу объяснить это вам. Кроме того, я воспроизвёл этот эффект не только для текста, но и для растровых изображений и SVG, а так же написал несколько примесей Sass, чтобы облегчить работу с ним.

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

— Прототипное наследование — это прекрасно
JavaScript — это объектно-ориентированный (ОО) язык, уходящий корнями в язык Self, несмотря на то, что внешне он выглядит как Java. Это обстоятельство делает язык действительно мощным благодаря некоторым приятным особенностям.

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

К счастью, в ECMAScript 5 появилось множество вещей, которые позволили поставить язык на правильный путь (некоторые из них раскрыты в этой статье). Также будет рассказано о недостатках дизайна JavaScript и будет произведено небольшое сравнение с классической моделью прототипного ОО (включая его достоинства и недостатки).

Многие из нас слышали о Hazelcast. Это удобный продукт, который реализует различные распределенные объекты. В частности: key-value хранилища, очереди, блокировки и т.д. К нему в целом применяются утверждения о распределенности, масштабируемости, отказоустойчивости и другие положительные свойства.

Так ли это применительно к его реализации очередей? Где границы их использования? Это мы и попытаемся выяснить.

В релизе Java 8 появился новый класс Optional призванный помочь разработчикам в обработке NullPointerException.

С NullPointerException встречались многие и во многих случаях, это очень неприятное исключение заставляет дебажить код, дабы понять, в каком месте, кто-то из твоих предшественников(а возможно и ты), не поставили пресловутую проверку на null.

А что если вообще запретить назначать тем или иным полям класса значения равные null? Java естественно не запрещает нам делать этого, но с Optional это становится немного удобнее и нагляднее.

Итак, приступим к описанию основных возможностей этого нововведения.

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

И однажды мне пришла в голову мысль облегчить себе жизнь, встроив groovy shell в приложение, сделав доступ к нему через telnet.

В данной статье я бы не хотел заострять внимание на принципе работы сборщика мусора — об этом прекрасно и наглядно описано здесь: habrahabr.ru/post/112676. Хочется больше перейти к практическим основам и количественным характеристикам по настройке Garbage Collection в JVM — и попытаться понять насколько это может быть эффективным.

Количественные характеристики оценки эффективности GC

Рассмотрим следующие показатели:

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

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

В последнее время в научных публикациях всё чаще упоминается алгоритм достижения консенсуса в распределенных системах под названием Paxos. Среди таких публикаций ряд работ сотрудников Google (Chubby, Megastore, Spanner) ранее уже частично освещенных на хабре, архитектуры систем WANdisco, Ceph и пр. В то же время, сам алгоритм Paxos считается сложным для понимания, хоть и основывается он на элементарных принципах.

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

Психология — интересная и иногда полезная наука. Многочисленные исследования показывают, что задержка в отображении веб-страницы дольше 300 мс заставляет пользователя отвлечься от веб-ресурса и задуматься: «что за хрень?». Поэтому УСКОРИВ веб-проект до психологически невоспринимаемых значений, можно ПРОСТО удерживать пользователей дольше. И именно поэтому бизнес готов тратиться на скорость: $80М — чтобы уменьшить latenсy всего на 1 мс.



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

Добрый день.
В рамках набора на курс «Multicore programming in Java» я делаю серию переводов классических статей по многопоточности в Java. Всякое изучение многопоточности должно начинаться с введения в модель памяти Java (New JMM), основным источником от авторов модели является «The Java Memory Model» home page, где для старта предлагается ознакомится с JSR 133 (Java Memory Model) FAQ. Вот с перевода этой статьи я и решил начать серию.
Я позволил себе несколько вставок «от себя», которые, по моему мнению, проясняют ситуацию.
Я являюсь специалистом по Java и многопоточности, а не филологом или переводчиком, посему допускаю определенные вольности или переформулировки при переводе. В случае, если Вы предложите лучший вариант — с удовольствием сделаю правку.
Этот статья также подходит в качестве учебного материала к лекции «Лекция #5.2: JMM (volatile, final, synchronized)».

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

Ну и да, приходите учиться ко мне!

---

JSR 133 (Java Memory Model) FAQ

Jeremy Manson и Brian Goetz, февраль 2004

Содержание:
Что такое модель памяти, в конце концов?
Другие языки, такие как C++, имеют модель памяти?
Что такое JSR 133?
Что подразумевается под «переупорядочением» (reordering)?
Что было не так со старой моделью памяти?
Что вы подразумеваете под «некорректно синхронизированы»?
Что делает синхронизация?
Как может случиться, что финальная поля меняют значения?
How do final fields work under the new JMM?
Что делает volatile?
Решила ли новая модель памяти «double-checked locking» проблему?
Что если я пишу виртуальную машину?
Почему я должен беспокоиться?

Пирамидальная сортировка (она же сортировка кучей) – классический алгоритм который, пожалуй, должен знать любой программист. Старая добрая «пирамидка» примечательна тем, что в независимости от набора данных у неё одна и та же сложность по времени (причём, очень пристойная) – O(n log n). Лучших и вырожденных случаев для неё нет.

С момента изобретения метода (а в этом году алгоритм празднует свой полувековой юбилей) было немало охочих кардинально оптимизировать процесс накладывания сортирующих куч. Тернарная пирамидальная сортировка, плавная сортировка, сортировка декартовым деревом – вот неполный список инноваций. Перечисленные алгоритмы хотя при тестировании и опережают оригинал по абсолютной скорости кто на 12, а кто и на 25%, в оценке временной сложности всё равно крутятся вокруг O(n log n). При этом данные методы весьма изощрённо реализованы.

Своё видение пирамидальной сортировки предложил и скромный труженик Университета Манитобы Джейсон Моррисон. При этом способ в некоторых случаях по скорости приближается к O(n).

Scope определяет жизненный цикл объекта. Например, java-бин (далее просто бин) определённый в RequestScope создается при получении http запроса и освобождается при завершении данного запроса. В JEE и в Spring есть возможность создавать свой собственный scope. Т.е. мы можем создавать объекты со своим собственным жизненным циклом — они будут создаваться по какому либо нашему событию и также уничтожаться. В JEE за это отвечает спецификация CDI (Context and Dependency Injection) и на самом деле там уже есть один подобный встроенный scope. Это ConversationScope. У нас есть API и аннотации для начала и окончания conversation. Если мы их не используем, то по-умолчанию ConversationScope ведет себя как RequestScope. Для отслеживания conversation каждого отдельного клиента используется специальный conversationId, который обычно добавляется как параметр http запроса. Но такой подход не работает для веб-сервисов. А в Spring вообще нет ничего подобного. Но в моей практике заказчик попросил сделать веб-сервис, который бы использовал одно и то же физическое соединение к внешней системе для нескольких последовательных вызовов. Также надо было хранить некоторое количество дополнительных данных. Т.е. надо было сохранять некое состояние (объект с соединением и данными) на определённый промежуток времени, такой аналог conversation scope для веб-сервиса. Можно, конечно, сохранить этот объект в Мар, где ключом будет наш аналог conversationId, а Мар положить в ServleContext и доставать это всё из методов веб-сервиса. Но это неудобно. Гораздо удобнее, когда сам сервер будет инжектить нам наш объект по заданному conversationId. Поэтому, сделаем свой scope, который будет работать с SOAP веб-сервисом. Сам по себе веб-сервис не может принадлежать какому-либо scope, но наш бин, который мы будем инжектить в веб-сервис, будет принадлежать нашему scope.

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

Именно этим мы и займёмся.

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

Нам удалось заманить в студию Дмитрия Коткина, руководителя Санкт-Петербургской школы переговорщиков ШиП, который имеет широкий опыт переговоров — от работы в политике до консультирования IT-компаний. Несмотря на температуру, Дима продержался в кадре 20 минут и рассказал, как профессиональные переговорщики рекомендуют противостоять формуле нужды:



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

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

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

После статьи «Управленческие инструменты: 4-фазный алгоритм решения проблем с людьми или «А чего ты хочешь, если ты такой хреновый менеджер?» нам писали: мол, ну так же не бывает, что со всем людьми и во всех случаях этот алгоритм работает? Это правда — этот алгоритм не очень хорошо работает, когда другой человек не видит с вами общего будущего. И/или же хочет вас банально отжать на что-то.

Один из самых полезных управленческих опытов в своей жизни я получил от руководства ремонтом собственной квартиры. На тот момент я уже 4 года работал менеджером — сначала руководил командой по тестированию Java на мобильных устройствах (мы работали с Sun), потом руководил командой в Intel. Я прочел Тома Демарко. Джоэла Спольски, прошел несколько управленческих тренингов. В общем, чувствовал себя очень крутым управленцем. Но это меня не спасло.

Управление ремонтом квартиры требует немного других навыков, тем более когда тебе противостоит опытный прораб. Мой прораб в самом начале сотрудничества применил переговорный инструмент “Формула нужды”, чем и обеспечил себе однозначную и безоговорочную победу.

Сам по себе инструмент достаточно часто применяется в переговорах с заказчиками — прежде всего, ими и применяется. Итак, как выглядит Формула нужды:

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

Зачем? Ведь можно быстро посчитать на гаджете. Увы, совсем не быстро, т.к. потребуется время на поиски и активацию гаджета, поиск приложения, ввод даты, осознание полученного результата. А еще можно друзей/подруг порадовать своими внезапно появившимися экстраординарными способностями. Кстати, друзья быстро осознают удобство использования вечного календаря с голосовым интерфейсом.

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

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

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

Через некоторое, не долгое время, я наткнулся на замечательную библиотеку — sigmajs, на тот момент была версия 0.8.2, если мне не изменят память, которая удовлетворила почти все наши амбициозные потребности.

С тех пор, много воды утекло, появилась версия сигмы 1.0.0, я обрел новый багаж знаний в сфере JS + Canvas и веба в целом. Для тех, кого я заинтриговал, прошу под кат, где будет дан краткий обзор библиотеки — sigmajs.

Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

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

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

Итак, как создать анонимный блог.