У меня — 'cd'.

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

Но должны же быть решения!

В моей любимой оболочке zsh есть такая возможность — «разворачивание» путей по нажатию : например, "/u/in/sy" -> "/usr/include/sys/"

В остальных оболочках можно приноровиться и использовать $CDPATH или pushd/popd, но лично мне это до сих пор кажется неудобным.

А еще есть пара утилиток для ускоренной навигации. Самая известная из них, пожалуй, autojump. Она следит в каких папках пользователь проводит больше всего времени и позволяет указывать только фрагмент пути к папке. Например "incl" приведет вас в "/usr/include", если вы там часто бываете.

Autojump вдохновила другого разработчика на создание утилиты "z". "Z" использует в качестве критерия для перехода т.н. "frecency" - комбинацию частоты посещений папки (frequency) и времени последнего перехода туда (recency).

Обе утилиты хороши по-своему, и я так бы и пользовался autojump или z, однако что-то мне не давало покоя. А недавно я услышал одну фразу:

If the product is used as a tool, its interface should be as unintelligent as
possible. Stupid is predictable; predictable is learnable; learnable is usable.

И тут я понял что самое время придумать свой велосипед. Не-intelligent. Тупой и удобный.

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

Под катом будет рассказ, как мы стараемся организовать эти процессы, какие инструменты создаём для препарирования SPA. Кроме этого, мы поговорим о технических подробностях реализации Live Coding / Hot Reload и чуток о VirtualDom и React с Angular.

В 2014 году я выступил на открытии конференции GopherCon с докладом под названием «Go: Best Practices for Production Environments». В SoundCloud мы были одними из первых пользователей Go и к тому времени уже два года писали на нём и поддерживали Go в бою в той или иной форме. За это время мы кое-чему научились, и я попытался поделиться частью этого опыта.

С тех пор я продолжал программировать на Go в течение всего рабочего дня, сначала в командах SoundCloud, отвечающих за операционную деятельность и инфраструктуру, а теперь работаю в компании Weaveworks над Weave Scope и Weave Mesh. Также я усердно трудился над Go kit, набором инструментов для микросервисов с открытым исходным кодом. И всё это время я принимал активное участие в развитии сообщества Go-программистов, встречался со многими разработчиками на митапах и конференциях по всей Европе и в США, коллекционируя их истории успехов и провалов.

В ноябре 2015-го, на шестую годовщину релиза Go, я вспоминал то своё первое выступление. Какие из лучших практик прошли проверку временем? Какие из них устарели или стали неэффективными? Появились ли какие-то новые методики? В марте мне представилась возможность выступить на конференции QCon London, где я рассказал о лучших практиках 2014 года и дальнейшем развитии Go до 2016 года. В этом посте представлена выжимка из моего выступления.

Ключевые положения я выделил в тексте в виде Top Tips — лучших советов.

А вот и cодержание:

1. Среда разработки
2. Структура репозитория
3. Форматирование и стиль
4. Конфигурация
5. Разработка программы
6. Логирование и метрики
7. Тестирование
8. Управление зависимостями
9. Сборка и развёртывание
10. Заключение

Продолжение цикла переводов полезных советов для веб-разработчика. Другие части: 1-16, 33-48.

Содержание:
   17.  Быстрое редактирование названия HTML-тега в панели «Elements»
   18.  Разворачивание всех дочерних узлов выбранного элемента
   19.  Переключение состояния вкладки DevTools при помощи горячих клавиш
   20.  Переключение на DOM-элемент из DevTools консоли
   21.  Подсветка выполняемого выражения
   22.  Улучшения в работе инструмента Color Picker
   23.  Включение точки останова и навигация по стеку вызовов при помощи горячих клавиш
   24.  Просмотр определения функции, зарегистрированной как обработчик события на DOM-элементе
   25.  Нотификация о JS-ошибке во время написания кода
   26.  Персистентность настроек отображения для режима «Инкогнито»
   27.  Визуализация выбранного режима сглаживания анимации
   28.  Просмотр и изменения точек останова DOM-дерева при помощи панели «Breakpoints»
   29.  Пять интересных возможностей панели «Console»
   30.  Автодополнение свойств и методов объекта в панели «Console»
   31.  Просмотр и отладка обработчиков событий
   32.  Автоматическая остановка выполнения программы при возникновении любых исключений

Команда браузера Google Chrome проделывает огромную работу для того, чтобы разработчикам жилось лучше. Chrome DevTools — пример замечательного инструмента, сильно упрощающего отладку вашего веб-приложения. Но подчас не весь функционал этой системы виден с первого взгляда, поэтому Umar Hansa — программист из Лондона — описывает его на своем сайте, причем в весьма удобном формате: немного текста и короткий скринкаст. А мы, в свою очередь, решили сделать эти советы более доступными русскоязычной аудитории.

Содержание:

1. Перенаправление порта позволит вам открывать локальные ссылки на мобильном устройстве
2. Активация псевдо-классов DOM-элемента
3. Повтор сетевого запроса при помощи cURL
4. Запуск сохранённых блоков кода (сниппетов) на любой веб-странице
5. Отслеживание изменений файлов через DevTools
6. Простая запись действий страницы
7. Поиск элементов DOM-дерева при помощи CSS-селекторов
8. Копирование изображения в формате Data URI
9. Переход к нужной строке при открытии файла
10. Упрощенная навигация между правками
11. Копирование ответа на сетевой запрос
12. Работа с несколькими курсорами при редактировании скриптов
13. Блочное выделение
14. Быстрый мониторинг событий в консоли
15. Доступ к выбранному DOM-узлу в консоли
16. Отслеживание незавершенных сетевых запросов при помощи фильтра is:running

Продолжение: 17-32, 33-48.

Менеджер многопоточных закачек на GO.

http://loafter.github.io/godownloader/
https://github.com/Loafter/godownloader

Вступление

Давным-давно, в году этак 1998, для выхода в интернет я использовал модем на работе у отца. Он его включал вечером после работы и я мог наслаждаться просторами сети интернет на скорости аж 31.2 кбит/c. В то время не было истеричных блогеров, страницы не весили по мегабайту, а в новостных сайтах говорили только правду. Естественно основной интерес представляли ресурсы. Картинки, программы, всякие дополнения к играм, вроде машинок. Как сейчас помню качать через IE было сущим адом. Скачать файл весом больше 500 кб было просто невозможно, древний осел был намного упрямей.

Raspbian является рекомендуемым дистрибутивом для всех, кто начинает своё знакомство с Raspberry Pi, проблема лишь в том, что по умолчанию в него включено множество пакетов. А так как очень не многие используют малинку в качестве десктопа, то эти пакеты вряд ли можно считать необходимыми. На просторах Интернета можно найти образы минималистичных версий (например, из этой статьи), но к сожалению 2 представленные там версии (Raspbian Server Edition и Raspbian Minimal) не обновлялись уже более 2 лет.

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

P.S. У знатоков Linux систем с этим вряд ли возникнут проблемы, а новичкам может быть полезно.

Устройство для снимка экрана на первых компьютерах (Command-Shift-3)

Если вы когда-либо делали хелп или мануал для своего приложения, наверняка вы отметили, как неожиданно много времени и сил занимает создание скриншотов.

Ведь кажется, что скриншот — это “секунда работы, Alt+PrintScreen и Ctrl+V!”. Некоторые клиенты удивляются, когда слышат, что скриншот в мануале может стоить и $2 и даже $5.

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

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

Сегодня практически в любом доме есть Wi-Fi роутер и было бы недальновидно не воспользоваться этим устройством для домашней автоматизации, тем более что сегодня на рынке есть все доступное оборудование для реализации любых идей. Ниже будет представлен вариант создания небольшого электронного устройства, являющегося платформой для построения различных датчиков/исполнительных механизмов на основе Wi-Fi модуля — ESP8266.

На Хабре уже есть статьи о NoSQL СУБД Tarantool и о том, как его используют в Mail.Ru Group (и не только). Однако нет рецептов того, как работать с Tarantool на Python. В своей статье я хочу рассказать о том, как мы готовим Tarantool Python в своих проектах, какие проблемы и сложности при этом возникают, плюсы, минусы, подводные камни и, конечно же, «в чем фишка». Итак, обо всем по порядку.



Tarantool представляет собой Application Server для Lua. Он умеет хранить данные на диске, обеспечивает быстрый доступ к ним. Tarantool используется в задачах с большими потоками данных в единицу времени. Если говорить о цифрах, то это десятки и сотни тысяч операций в секунду. Например, в одном из моих проектов генерируется более 80 000 запросов в секунду (выборка, вставка, обновление, удаление), при этом нагрузка равномерно распределяется по 4 серверам с 12 инстансами Tarantool. Не все современные СУБД готовы работать с такими нагрузками. Кроме того, при таком количестве данных, очень дорого ожидание выполнения запроса, поэтому сами программы должны быстро переключаться от одной задачи к другой. Для эффективной и равномерной загрузки CPU сервера (всех его ядер) как раз нужен Tarantool и асинхронные приемы в программировании.

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

UPD: к нижеприведенному материалу поступило множество дельных замечаний, поэтому он был полностью переработан: habrahabr.ru/company/makeitlab/blog/252015

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

Эта история должна помочь разработчикам “хардверных” продуктов, сэкономить их время при выборе технологий 3D печати и уберечь от ошибок.

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

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

С чего все началось

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

Предисловие.

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

Преамбула

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



Мне надоели эти баталии, и я решил, что пришло время найти какую-нибудь компактную замену стандартной 104-кнопочной клавиатуре.

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

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

10. Мини-приложения

Начать список мы решили не с одного, а сразу с набора приложений. Остановимся на тех, которые выполняют одну простую функцию, но выполняют ее отлично. Среди них Every Time Zone (показывает текущее время во всех часовых поясах), Umbrella Today? (сообщает, понадобится ли вам сегодня зонтик) и notepad.cc (минималистичный блокнот). Еще есть Spreeder, который позволяет вам читать текстовую информацию заметно быстрее обычного; SleepyTime — скажет, когда вам нужно лечь спать, чтобы проснуться в оптимальное время; а также SimplyNoise, умеющий генерировать так называемый белый шум.

За кадром осталось еще много “умных” и полезных веб-утилит, для описания которых нам здесь просто-напросто не хватит места. Но вот вам все же несколько вдогонку: 0to255, Mixest, PDFMyURL, и Copy Paste Character.

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

Сходу расстрою — посылкой управлять никак нельзя. Если она долго не «прилетает» в Россию (т.е. статус Экспорт стоит, а Импорт — нет) — тут вряд ли что-то поможет. Однако страхуемся, делаем по шагам, описанным ниже.
Порадовать тоже могу: процентов 95 посылок все-таки доходят. Объем для сравнений — порядка 10 посылок в месяц из США и Европы.
Обращаю внимание, что многие посылки (процентов 60 всех отправлений) я получаю «от себя», используя сервисе вроде Шипито. В некоторых случаях это означает, что почта не может отказать в претензиях по причине того, что они представляются «не отправителем». Однако во многих случаях рекомендую идти и биться за свою посылку при помощи процессов и документов, представленных ниже.

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

Я и мои друзья давно пользуются программой Gyazo.

Вкратце: маленькая программка, при запуске которой можно сразу выделять область на экране, а как только отпускаешь мышку, область закачивается на сервер gyazo, а в буфер обмена сразу копируется ссылка на него.
Попробовать можно здесь: http://gyazo.com

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

Сначала, в буфер копировалась не прямая ссылка на картинку, а ссылка на страничку с рекламой. Затем и вовсе прямой файл стал недоступен.

Поскольку gyazo является Open Source проектом, я решил сделать версию «для себя» и без рекламы.

Уже давно фотоаппараты являются, по сути, специализированными компьютерами. Например, в устройствах фирмы Canon используется процессор ARM и операционная система DRYOS. Естественно, у энтузиастов возникла идея модификации программной части этих фотоаппаратов. Хочу обрадовать обладателей устройств фирмы Canon серий 1100D, 500D, 550D, 600D, 50D, 60D, 5D Mark II. Теперь вы можете прошить свой аппарат, улучшив его функциональность. Получить устройство, которое обладает возможностями, включаемыми только в дорогую профессиональную фото и видеотехнику. А может быть, вооружившись ARM-Toolchain, разработать новые функции.