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



Под инструментом тайм-менеджмента я подразумеваю некие действия со своими задачами, которые приводят к увеличение свободного времени или сокращению времени на задачу (что суть есть одно и тоже = высвобождение времени).

У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.

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

Данная статья дает общее, но вовлеченное представление о восьми самых интересных, на мой взгляд, JavaScript-библиотеках для построения интерактивных геовизуализаций. В целом, таких решений сейчас много, и выбрать оптимальное под тот или иной конкретный проект – задача порой непростая как минимум по времени. Этой публикацией я попытаюсь хотя бы немного упростить жизнь тем, кто только начинает разбираться в данной теме. Кстати, это слегка модифицированный перевод моей недавней статьи на Onextrapixel (оригинал на английском).

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

Но врожденные любознательность и энтузиазм довели меня до того, что я стал одним из разработчиков Synaptic — проекта фреймворка для построения нейронных сетей на JS с 3к+ звезд на GitHub. Сейчас мы с автором фреймворка занимаемся созданием Synaptic 2.0 с ускорением на GPU и WebWorker-ах и с поддержкой почти всех основных фич любого приличного NN-фреймворка.

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

Jupyter Notebook – это крайне удобный инструмент для создания красивых аналитических отчетов, так как он позволяет хранить вместе код, изображения, комментарии, формулы и графики:



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

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

Что вы сделаете? Ну, традиционный путь — взять ещё одну хранилку на 30–35 Тб (но подешевле раз в пять, помедленнее, попроще, без резервирования) и отреплицировать базу на неё. А затем работать с копией. Хороший план?

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



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

Продолжаем цикл статей о контейнеризации. Сегодня мы поговорим о runC — инструменте для запуска контейнеров, разрабатываемом в рамках проекта Open Containers. Цель этого проекта заключается в разработке единого стандарта в области контейнерных технологий. Проект поддерживают такие компании, как Facebook, Google, Microsoft, Oracle, EMC, Docker. Летом 2015 года был опубликован черновой вариант спецификации под названием Open Container Initiative (OCI).

H.264 — стандарт сжатия видео. И он вездесущ, его используют для сжатия видео в интернете, на Blu-ray, телефонах, камерах наблюдения, дронах, везде. Все сейчас используют H.264.

Нельзя не отметить технологичность H.264. Он появился в результате 30-ти с лишним лет работы с одной единственной целью: уменьшение необходимой пропускной способности канала для передачи качественного видео.

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

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

Теперь ReactOS можно запустить почти в любом современном веб-обозревателе при помощи браузерной виртуальной машины Virtual x86. Эта необычная среда виртуализации не требует установки, написана на JavaScript и работает как в вашем браузере, так и на NodeJS. Ранее о ней уже писали на Хабре: [1], [2].

Содержание первой части:

1.1 — Создание виртуальной лаборатории (чтобы нам было где работать, я покажу как создать виртуальную сеть на вашем компьютере. Сеть будет состоять из 3х машин Linux ubuntu).
1.2 – Написание простого модуля в Linux. Введение в Netfilter и перехват трафика с его помощью. Объединяем все вместе, тестируем.
1.3 – Написание простого char device. Добавление виртуальной файловой системы — sysfs. Написание user interface. Объединяем все вместе, тестируем.

Содержание второй части:

В жизни любого развивающегося проекта рано или поздно (и лучше рано) наступает момент, когда эксплуатация многозначительно смотрит на разработку и предлагает оформить отношения. Дальнейшее развитие событий, как водится, зависит от обеих сторон. О плохом сегодня не будем, рассмотрим сразу случай, когда разработка готова использовать нехитрый инструментарий сборки пакетов, подготовленный для нее эксплуатацией (шаблоны debian/rules и debian/control, команды fakeroot, debuild, и так далее). Осталась самая малость: поднять для собранных пакетов собственный репозиторий.

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

Отныне я не буду больше создавать нативные приложения. Все мои приложения в дальнейшем будут прогрессивными веб-приложениями (PWA, Progressive Web Apps). Это такие приложения, которые предназначены для еще более органичной работы на мобильных устройствах, чем нативные приложения.

Что я имею ввиду под «более органичной работой»? Большая часть веб-траффика исходит от мобильных устройств и пользователи устанавливают в среднем от 0 до 3 новых приложений в месяц. Это означает, что люди не тратят много времени на поиск новых приложений в App store, но они проводят много времени в сети, где могут найти и использовать ваше приложение.

Прогрессивные веб-приложения начинают свою работу как любое другое веб-приложение, но когда пользователь возвращается в приложение и показывает (фактом использования), что он заинтересован в более регулярном обращении к приложению, браузеры предложат пользователю установить приложение на свой домашний экран. PWA также могут использовать push-уведомления как и нативные приложения.

Содержание

1. Введение в Computer Science
2. Структуры данных и Алгоритмы
3. Системное программирование
4. Распределенные системы
5. Базы данных
6. Объектно-ориентированный дизайн и разработка софта
7. Искусственный интеллект
8. Машинное обучение
9. Веб-разработка и интернет-технологии
10. Concurrency
11. Компьютерные сети
12. Разработка мобильных приложений
13. Математика для программистов
14. Теория информатики и языки программирования
15. Архитектура компьютера
16. Безопасность
17. Компьютерная графика
18. Работа с изображениями и компьютерное зрение
19. Интерфейс Человек-Компьютер
20. Вычислительная биология
21. Прочее

Введение

Привет всем! Несколько месяцев назад на Хабре была опубликована статья «Вещание онлайн-видео с помощью nginx» , в которой Aecktann рассказал о своем опыте внедрения разрабатываемого мной модуля к nginx для вещания видео — nginx-rtmp-module. С тех пор продукт активно развивался и в этой статье я более подробно расскажу о нем.

Вещатель нужен для передачи видео-потока клиенту. Речь идет либо о живом потоке, либо о вещании записанного видео (VOD, Video-on-demand). Существует большое количество технологий вещания видео. Среди них можно выделить традиционные протоколы, такие как RTMP или MPEG-TS, а также появившиеся в последнее время технологии адаптивного вещания поверх HTTP. К последним относятся HLS (Apple), HDS (Adobe), Smooth Streaming (Microsoft), MPEG-DASH. При выборе технологии основным фактором является ее поддержка на клиентской стороне. Именно поэтому вещание в формате RTMP на текущий момент является одним из самых распространенных. Протокол HLS поддерживается устройствами компании Apple, а также некоторыми версиями Android.

Эта статья призвана познакомить читателя с находящимся в арсенале systemd набором инструментов.

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

Несколько лет назад Фабрис Беллар написал jslinux — эмулятор ПК, написанный на JavaScript. После этого был ещё как минимум Virtual x86. Но все они, насколько мне известно, являлись интерпретаторами, в то время как написанный значительно раньше тем же Фабрисом Белларом Qemu, да и, наверное, любой уважающий себя современный эмулятор, использует JIT-компиляцию гостевого кода в код хостовой системы. Мне показалось, что самое время реализовать обратную задачу по отношению к той, которую решают браузеры: JIT-компиляцию машинного кода в JavaScript, для чего логичнее всего виделось портировать Qemu. Казалось бы, почему именно Qemu, есть же более простые и user-friendly эмуляторы — тот же VirtualBox, например — поставил и работает. Но у Qemu есть несколько интересных особенностей

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

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

И вот, после двух лет неспешного ковыряния в свободное время исходников Qemu появился работающий прототип, в котором уже можно запустить, например, Kolibri OS.

Обо мне

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

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

Во Вселенной работает довольно жестокий вид кармы.

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

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

Про Scrum часто можно услышать фразы вроде «православный Scrum», «мы используем best practices из Scrum» или «что почти всегда остается» от техник Scrum при его реализации.

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

В общем, как я уже читал тут в комментах: «целые статьи пишут на то, как добавить 5 символов и пробел в конфиг». Все бы хорошо, если бы не google chrome. Они решили прекратить поддержку SPDY и NPN(кому интересно, вот комментарий chromium по этому поводу).

Эта статья является продолжением цикла о написании умных контрактов на платформе Ethereum. В первой части я пообещал показать, как создать новую криптовалюту на Solidity (в мире блокчейна это является чем-то вроде аналога "Hello, world!"). Но на самом деле в этом нет смысла, так как об этом уже написано несколько хороших статей (пример из доков Solidity, пример с главной страницы Ethereum).

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

BTW все написанное ниже имеет чисто образовательный характер.