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

Так какого же чёрта моё прекрасное IT превращается в детский сад «Весёлый Програм-Мишка»?

Это первая часть про символы и их использование в JavaScript.

Новая спецификация ECMAScript (ES6) вводит дополнительный тип данных — символ (symbol). Он пополнит список уже доступных примитивных типов (string, number, boolean, null, undefined). Интересной особенностью символа по сравнению с остальными примитивными типами является то, что он единственный тип у которого нет литерала.

Для чего же нужен был дополнительный тип данных?

В JavaScript нет возможности объявить свойство объекта как приватное. Чтобы скрыть данные можно использовать замыкания, но тогда все свойства нужно объявлять в конструкторе (так как нет возможности объявить их в прототипе), к тому же они будут создаваться для каждого экземпляра, что увеличит размер используемой памяти. ECMAScript 5 предоставил возможность указать enumerable: false для свойства, что позволяет скрыть свойство от перечисления в for-in и его не будет видно в Object.keys, но для этого нужно объявлять его через конструкцию Object.defineProperty.

Привет, Хабр!
Мы в Хекслете активно используем Докер как для запуска самого приложения и сопутствующих серверов, так и для запуска пользовательского кода в практических упражнениях по программированию. Без этих легковесных контейнеров нам было бы в разы сложнее справиться с этими задачами. Докер –замечательная технология, но иногда возникают неожиданные проблемы. Одна из таких проблем (и ее решение) описана в блоге Phusion (это создатели Phusion Passenger), сегодня мы публикуем ее перевод.

Примерно год назад, когда Докер был в версии 0.6, мы первыми представили Baseimage-docker. Это минимальный образ Ubuntu, модифицированный специально для Докера. Люди могут пуллить этот базовый образ из Docker Registry и использовать его как основу для своих образов.

Мы были ранними пользователям Докера, используя его для CI и для создания рабочего окружения задолго до выхода версии 1.0. Базовый образ мы сделали чтобы решить проблемы, специфичные для принципов работы Докера. Например, Докер не запускает процессы под специальным процессом init, который бы правильно обрабатывал дочерние процессы, поэтому возможна такая ситуация, когда зомби-процессы вызывают кучу проблем. Докер также не делает ничего с syslog, поэтому важные сообщения могут быть утеряны. И так далее.

Однако, мы выяснили, что многие люди не понимают проблем, с которыми мы столкнулись. Да, это довольно низкоуровневые системные механизмы Unix, которые понятны далеко не всем. Поэтому в этом посте мы опишем самую главную проблему, которую мы решаем – PID 1 zombie reaping problem.

Муда, что по-японски означает «потери» — это любая деятельность, которая потребляет ресурсы, но не создает ценности для клиента. (Источник).



Эта короткая заметка для тех, кто системно ищет, где его студия теряет деньги. Похвальное занятие в наше весёлое время.

Хорошо систематизировали виды потерь ребята из Toyota. Тойотовцы выделяют 7-8 видов муды, потерь на производстве. Посмотрим, есть ли аналоги между потерями в автомобилестроении и работе студии.

Мы продолжаем знакомить вас с переводами статей Chris Bailey, где он делится советами, которые извлек во время проекта «a Year of Productivity». Ранее мы публиковали статьи этого автора, они доступны в нашем блоге в разделе «личная продуктивность».

Итак, даем слово Крису!

Лет пять назад в моей жизни наметилась неприятная закономерность: я стал замечать, что процент выполнения «целей на год» год от года уменьшался, и достиг в итоге катастрофической отметки в районе 12%. При этом у меня абсолютно не было ощущения провального года, поэтому я начал подозревать что что-то не так. В результате несколько лет экспериментировал с постановкой целей, попутно изучая теорию и дискутируя с GKh. В результате мне удалось сформулировать способы постановки целей, максимизирующие вероятность их невыполнения – и хочу поделиться этим знанием с вами.

Операция слияния (merge), выполняемая стандартными средствами git, хорошо работает для текстовых файлов, содержащих исходные тексты программ. Но слияние текстовых файлов, содержащих жестко структурированные данные, в частности JSON — это большая головная боль.

Для решения этой проблемы можно подключить к git'у отдельный инструмент слияния для JSON-файлов, который не работает построчно, а учитывает структуру JSON-объектов.

Предлагаю использовать для этого скрипт на javascript, который анализирует сливаемые JSON-файлы и делает слияние на основании структуры и вложенности объектов JSON.

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

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

Осторожно, трафик! Но можно хотя бы посмотреть картинки )

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

 

Самым первым удивлением для меня было то, что Sony Reader приобрести в US оказалось не просто, а очень просто. Несмотря на то, что на сайте sony было указанно «заказы принимаются только на конец января в связи с большим спросом», первая попытка заказа с первого-же попавшегося веб магазина (circuitcity.com) завершилась немедленным успехом. Все заказалось и доставилось за пару дней, и открыв коробку я обнаружил там вожделенный Reader. В комплекте шел чехол/обложка, блок питания для зарядки и обычный USB кабель с мелким разъемом на одном конце. Забегая вперед скажу, что блок питания не очень понятно зачем нужен. Зарядка от USB вполне работает.

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

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

Включение ридера никакого напряжения мысли не вызвало, и инструкций читать не заставило. Очень явный включатель на торце был обнаружен мгновенно но само включение проистекало довольно долго, не меньше минуты. Такое время ожидание бывает только после перезагрузки либо после первого включение. В нормальной ситуации, ридер запускается за 1-3 секунды. Кстати, кнопка reset расположена таким образом, что нажать ее не снимая обложки невозможно. Хотя за неделю работы никакой необходимости ее нажимать не возникло, я проверил ее работу и время перезагрузки, любопытства ради.

Первая картинка которую ридер показал, произвела на меня очень сильное впечатление. Там было его основное меню из 10 пунктов, полностью покрывающее площадь экрана. Пункты вполне ожидаемые — Books / By Author / By Date / Collections / All Bookmarks / Now Playing / Audio / Pictures / Settings. Но конечно, не текст меню произвел шоковое впечатление, а то, как это выглядело на экране. Sony Reader как известно использует экран на основе «Электронных чернил» (eInc) и претендует на то, что бы быть «почти как настоящая бумага». И хотя мне экран не показался копией бумаги, но было очень четкое впечатление, что на чуть сером пластике напечатали на лазерном принтере. Ничего общего с другими экранами PDA и прочих компактных устройств. Это было похоже на что угодно, только не на
экран. Пожалуй на экране стоит остановится поподробней, т.к. это и есть то, для чего народ платит $350 за это устройство. Итак, если одним словом — «Невообразимо». Если еще пару слов добавить — «просто потрясающе». Это первый в моей многолетней практике электронного чтения экран, который настолько близок по ощущениям к обычной бумаге, и к которому практически не надо привыкать.

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

Контрастность экрана очень высокая — текст виден ясно и четко. Никакого мерцания экрана нет, т.к. eInc экраны не перерисовываются постоянно, а находятся (в момент показа текста) в стабильном состоянии. И питания при этом экран почти не потребляет. Забавным мне показалось определение длительности работы ридера, данное производителем — максимальное число переворачивания страниц. И число это немалое — около 7500!

Чтение с Sony Reader вполне комфортно при естественном и искусственном освещении. В темноте читать нельзя, но можно приспособить маленький светодиодный светильник, продающийся в книжных магазинах. Из моего опыта, одного светодиода оказалось мало, а вот светильник с парой — самый оптимум. Сам процесс чтения очень напоминает чтение обычных книг. Примерно так же часто «листается» страница и как обычную книгу, ридер можно оставить «открытым» (включенным). Через час он выключится сам.

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

Еще пара капель дегтя. Sony Reader не понимает русский язык прямо «из коробки». К счастью, русификация уже успешно накатана и делается за 5 минут. После этого, можно читать практически любые юникодные русские тексты в форматах TXT, RTF, PDF и его родном формате. Я для себя остановился пока на RTF файлах, в связи с простотой их изготовления и широким выбором готовых текстов в RTF. PDF файлы не изготовленные специально под его экран, читать трудно — очень мелко в полно-страничном режиме. Дело несколько улучшает перевод ридера в горизонтальный режим.

Тексты можно читать в 3х размерах (мелкий, средний, крупный). Первое переключение на новый размер для конкретной книги может занять секунд 20-60, для переформатирования. Подобное форматирование видимо происходит и при первой загрузке текста и может занять какое-то заметное время (минута-две).

В смысле совместимости с чем-либо, что не windows, ситуация условно-удовлетворительная. Условно, потому что к внутреннему хранилищу можно доступиться только из его родной программы существующей только для OS от Microsoft. Но слот для SD карточек вполне спасает ситуацию и позволяет легко и непринужденно копировать тексты прямо на флэш-карту из любой OS.

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

В заключение могу сказать 2 вещи. Во первых, Sony Reader PRS-500 на мой, читательский взгляд, вещь очень удачная и крайне уместная в хозяйстве читателя. Во вторых, хотя формально платформа и пока закрытая, но умельцы ее практически открыли. А это значит, что кроме русификации уже произведенной, можно вполне ожидать и добавления поддержки дополнительных форматов (HTML, FB2, CHM… ) да и разработки альтернативных программ чтения.

По многочисленным просьбам — перевод статьи «The Bumper List of Windows 7 Secrets».

Здесь пропущено вступление о том как здорово, что Windows 7 вышла в свет, которое все равно все пропустят и будут читать сами «секреты».

1. Управление окнами

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

• Win+Влево и Win+Вправо — прикрепить окно
• Win+Вверх и Win+Вниз — разворачивает и восстанавливает/сворачивает окно
• Win+Shift+Вверх и Win+Shift+Вниз — разворачивает и восстанавливает окно по вертикали

Решил я выйти из леса и найти команду своей мечты. Стряхнул пыль со своего резюме и… ничего нового не обнаружил — сотня однообразных вакансий с абстрактными требованиями: «отличное знание PHP и MySQL».

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

Ниже, как надо писать текст вакансии для программиста.

Не всегда есть возможность, да и не всегда надо, строить полноценный туннель с интерфейсной парой адресов. Иногда нам нужно лишь «прокинуть» вполне определённые порты.

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

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

Внимание, раздвоение истории!

Ветка 1
А к чёрту этот Модуль! Открываю текстовый редактор и пишу статью. Так как мысли лезут в голову сами, за день она легко делается. На следующий день, уже ни на что не отвлекаясь, пишу Модуль.
«Малодушно», скажете вы? Давайте рассмотрим альтернативное развитие событий.

Ветка 2
К чёрту эту Статью! Я мужественный программист и должен сначала закончить важное дело!
Целый день пытаюсь отмахиваться от мух посторонних мыслей. Стараюсь раскладывать Модуль на функции, а не на главы, и согласовывать интерфейсы, а не падежи. Итого, к концу дня едва начатый Модуль и чуть-чуть разрозненных записок по Статье, которые я всё-таки скинул в блокнот, чтобы выкинуть из головы.
На следующий день Статья забыта окончательно, и я спокойно доделываю Модуль.
На третий(!) день я пытаюсь вспомнить, что имел в виду в своих заметках по Статье. Но так как я от неё хорошо отгородился, получается так себе. Может быть, за этот день напишу. А может и нет, вдохновение то ушло.

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

Разумеется, не всё так просто. В таком поведении есть известные (и не очень известные) риски.

Так уж повелось, что программисты закрепляют удачные решения в виде шаблонов проектирования. По шаблонам существует множество литературы. Классикой безусловно считается книга Банды четырех «Design Patterns» by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides" и еще, пожалуй, «Patterns of Enterprise Application Architecture» by Martin Fowler. Лучшее из того, что я читал с примерами на PHP – это «PHP Objects, Patterns and Practice» by Matt Zandstra. Так уж получилось, что вся эта литература достаточно сложна для людей, которые только начали осваивать ООП. Поэтому у меня появилась идея изложить некоторые паттерны, которые я считаю наиболее полезными, в сильно упрощенном виде. Другими словами, эта статья – моя первая попытка интерпретировать шаблоны проектирования в KISS стиле.
Сегодня речь пойдет о том, какие проблемы могут возникнуть с инициализацией объектов в ООП приложении и о том, как можно использовать некоторые популярные шаблоны проектирования для решения этих проблем.

С распространением распределенных систем управления версиями (DVCS), таких как Git и Mercurial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.

Простой (изолированный) Feature Branch

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

Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).

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

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

1. Darcula

Главная и очень хорошая новость: в JetBrains работают (в частности stalk) над стандартной темной схемой. Она будет подключаться через look and feel и будет называться Darcula. Она уже включена в исходники для Comunity Edition и попадет в новые EAPы.

• На данный момент она выглядит вот так:
  
• А вот тут можно посмотреть видео: www.screenr.com/asl8

---

UPD. Вторая версия бенчмарка тут: eric.themoritzfamily.com/websocket-demo-results-v2.html

---

Предупреждение: если у вас есть претензии к бенчмарку и/или к коду, бенчмарк выложен на Гитхабе, что позволяет вам править баги самим или сообщить о багах автору.

Подробнее о проблеме 10000 соединений: ru.wikipedia.org/wiki/Проблема_10000_соединений

Как с проблемой 10000 соединений через вебсокеты справятся Erlang, Go, Haskell (Snap), Java (Webbit), Node.js (websocket) и Python (ws4py)?