Привет!

Меня зовут Рушан, и я автор Telegram‑канала Нейрон. Не забудьте поделиться с коллегами или просто с теми, кому интересны такие статьи.

Вкратце: пока не бросайте свой старый компьютер — используйте легкий дистрибутив Linux, чтобы возродить его!

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

Лучшие легкие дистрибутивы Linux для старых ноутбуков и десктопов

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

10. Peppermint

Peppermint  —  это облачно-ориентированный дистрибутив Linux, не требующий мощного железа для запуска. Он основан на Lubuntu и использует окружение рабочего стола LXDE для более плавной работы.

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

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

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

Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), — снизу.

Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API — это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем представления. Объедините все прямоугольники с API и обзовите слоем сервисов.

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

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

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

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

Теперь вам остаётся детально проработать каждый маленький квадратик.

Маленький практический пример запрячу под кат.

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

Учитывая вышесказанное, ненужный код – это зло по умолчанию. Он портится со временем. Он требует постоянной поддержки. Он содержит баги, которые нужно выискивать. Когда появляются новые функции, старый код приходится к ним приспосабливать. Чем больше у вас кода, тем больше ошибок может в нем затаиться. Чем больше времени занимают проверки или компиляции, тем дольше новый сотрудник будет разбираться в вашей системе.

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

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

Проект безопасности OWASP API Security Top 10 предназначен подчеркнуть потенциальные риски в небезопасных API и предложить меры снижения таких рисков.

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

My Why

Всем привет, меня зовут Аня, я продуктовый дизайнер в американской компании Scentbird NY, до этого занималась разработкой флагманских продуктов вместе с дизайн-командой Альфа-Банка.
Мне по жизни очень везёт, и я почему-то всегда работаю с разработчиками, которые предлагают самые интересные решения по продукту. Причем даже лучшие, чем могли бы предложить многие менеджеры и владельцы продуктов. И я заметила вот какую штуку: чем раньше вы подключаете разработчиков к работе над задачей, тем лучше получается результат. Под катом я расскажу, как проводить брейнштормы с командой так, чтобы генерировать не самые очевидные, но зато эффективные решения. Которые при этом еще и весьма просты в реализации. И, что главное, как не потратить на это уйму времени и не погрязнуть в согласованиях.

От переводчика

Представляемый вашему вниманию перевод открывает серию статей от Jakob Jenkov, посвященных внедрению зависимостей, или DI. Примечательна серия тем, что в ней автор, анализируя понятия и практическое применение таких понятий как «зависимость», «внедрение зависимостей», «контейнер для внедрения зависимостей», сравнивая паттерны создания объектов, анализируя недостатки конкретных реализаций DI-контейнеров (например, Spring), рассказывает, как пришел к написанию собственного DI-контейнера. Таким образом, читателю предлагается познакомиться с довольно цельным взглядом на вопрос управления зависимостями в приложениях.

В данной статье сравнивается подход к настройке объектов изнутри и извне (DI). По смыслу настоящая статья продолжает статью Jakob Jenkov Understanding Dependencies, в которой дается определение самому понятию «зависимости» и их типам.

Эта статья является попыткой ответа на старый вопрос для собеседований: «Что же случается, когда вы печатаете в адресной строке google.com и нажимаете Enter?» Мы попробуем разобраться в этом максимально подробно, не пропуская ни одной детали.

Примечание: публикация основана на содержании репозитория What happens when...

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

Мы перенесли перевод в репозиторий GitHub и отправили Pull Request автору материала — оставляйте свои правки к тексту, и вместе мы сможем значительно улучшить его.

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

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



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

У поисковиков не очень с логикой, это факт. Но они стараются. А SEO-специалисты стараются в ответ — пытаются добиться предельной релевантности страниц, опираясь на догадки и эксперименты.

Недавно Гугл порадовал новым фактором ранжирования — Neural Matching. Мы почитали, что об этом пишут эксперты, и собрали некоторые приемы, которые помогут писать более релевантные тексты под запросы.

И кстати, NM — это вам не LSI, все немного сложнее.

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

Если продукт действительно новый и аналогов нет — все верно, делать можно что угодно, проверяя гипотезу за гипотезой, и SEO тут будет в последних рядах. Но если продукт уже известен, например, в соседнем регионе и есть шанс раскрутить его в вашем? Или инновационный продукт расширяет возможности хорошо известного? Тут уже есть от чего отталкиваться.

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

Создать приложение для резервного копирования, работающее на любом дистрибутиве — задачка непростая. Чтобы обеспечить работу Veeam Agent for Linux на дистрибутивах от RHEL 6 и Debian 6, до openSUSE Leap 15.1 и Ubuntu 19.04 приходится решать спектр проблем, особенно если учесть, что в состав программного продукта входит модуль ядра.

Статья создана по материалам выступления на конференции LinuxPiter 2019.

Сначала о том, как 5 месяцев назад я проходил собеседование на работу. Меня посоветовал друг, и прошло уже немало времени, с момента как я ответил рекрутеру. Я был поражён, как сильно весь процесс изменился за последние 5 лет.

После первичного созвона меня отправили на сторонний сайт (HackerRank), чтобы я решил три небольших задачки за 1 час. Для меня это был первый подобный опыт. Первые две задачки были простыми, но третья оказалась посложней. Когда время подошло к концу, моё решение не проходило все тесты, а только где-то 8 из 10 необходимых.

Привет, меня зовут Игорь. Я десять лет работал в офисе, но год назад решился и перешел на удаленную работу. Для начала скажу, что теперь меня палкой не загонишь в офис! Перейти на удаленку было лучшее решение в моей жизни.

Привет, Хаброжители! Цель этой книги — дать вам знания, с помощью которых вы без колебаний присоединитесь к любому проекту, использующему эту библиотеку. Книга предназначена для всех, кто заинтересован в изучении Vue.js и имеет опыт работы с JavaScript, HTML и CSS. От вас не требуются глубокие знания этой области, но понимание основ, таких как массивы, переменные, циклы и HTML-элементы, не помешает.

Под катом представлен отрывок в виде главы «Vuex», описывающий: что такое состояние; использование геттеров; реализация мутаций; добавление действий; работа со вспомогательными методами Vuex; модули и настройка проекта.

Google недавно выпустила в публичный доступ новую версию Google Analytics под названием App + Web. Симо Ахава уже написал отличную пошаговую инструкцию о том, как начать работать с инструментом, поэтому я решила перевести ее на русский язык. От себя добавлю, что продукт только-только появился в бете и судя по всему еще будет существенно допиливаться. Мы уже начали тестировать новую структуру данных и возможности встроенной функции экспорта данных в Google BigQuery и надеемся вскоре рассказать подробнее о преимуществах и недостатках. В целом аналитики сегодня оценивают нововведения положительно. Например, Влад Флакс из OWOX BI считает, что этим обновлением Google упростил процесс сбора данных и их доставку из Google Analytics в BigQuery для тех проектов, которые готовы изменить структуру своих данных. К тому же, это повышает ценность Google BigQuery как DWH для маркетинг-данных.

В 2008 BigData была новым термином и модным трендом. В 2019 BigData – это объект продажи, источник прибыли и повод для новых законопроектов.

Осенью прошлого года российское правительство инициировало законопроект о регулировании больших данных. Запрещается идентифицировать по информации людей, но разрешается делать это по запросу федеральных органов. Обработка BigData для третьих лиц – только после уведомления Роскомнадзора. Под закон попадают компании, в распоряжении которых больше 100 тысяч сетевых адресов. И, конечно, куда без реестров – предполагается создание такового со списком операторов БД. И если до этого BigData не всеми воспринималась всерьез, то теперь с ней придется считаться.

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

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

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

Например, архитектурно GAN [1] состоит из генератора (GEN) и дискриминатора (DIS), Состязательный Автокодировщик (AAE) [2] состоит из Автокодировщика (AE) [3] и DIS,. Каждый компонент является отдельной вершиной в данном графе, поэтому для AAE у нас будет ребро с AE и DIS.

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

Недавно компания Яндекс запустила свою систему «умного дома». Нам предлагают купить недорогие работающие по Wi-Fi устройства: адаптер в розетку, лампочку и ИК пульт. Интересно, что у разработчиков «умных» устройств появилась возможность создать свои навыки «умного дома», это позволит подключить девайсы к системе Яндекса и управлять ими голосом через Алису. В списках навыков появляется всё больше новых брендов. Алиса прекрасно понимает русскую речь, что делает ее безусловным лидером среди голосовых ассистентов на российском рынке.
Однако, не всё так гладко…

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



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

Привожу неполный перевод исследования «Развитие зарплаты в зависимости от возраста». Гамбург, август 2019

Кумулятивный доход специалистов в зависимости от их возраста в евро брутто