Добрый день!

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

В связи с этим, при наличии желания увеличить скорость разработки и обеспечить единообразие продуктов, было решено разработать общую компонентную базу. О том, как создавался ui kit, и о долгих боях с дизайнерами мы умолчим, а вот о реализации данной задачи я и хочу поговорить.
На фронте у нас демократия или даже анархия. Люди вольны использовать те решения, с которыми им удобно работать. На данный момент в бою есть проекты на AngularJS, Angular, React, Vanilla, и есть также проекты на Vue для внутреннего использования. Вот на этом моменте наш взор и обратился на web components.

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

Мы занимаемся вопросами управления, организации труда и HR. Наша специализация – команды и компании, создающие интеллектуальный продукт. И наши клиенты хотят работать именно в таких коллективах, создавать такие команды и управлять именно такими компаниями.

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

И вот с чего мы начинаем.
Мы часто начинаем с вопросов про управление рабочей средой.
Концепция проста: есть факторы, мешающие работе – их надо постепенно нивелировать, есть факторы, способствующие работе – их надо включать и постепенно активизировать.
Ключевое слово – постепенно. Шаг за шагом. Системно.

Подробности под катом.

Visual Studio Code имеет git по умолчанию, но встроенных функций хватает не всегда для удобной и быстрой работы. Также для эффективной работы с git требуется визуализация процессов.

Rollup — это сборщик javascript приложений и библиотек нового поколения. Многим он давно знаком как перспективный сборщик, который хорошо подходит для сборки библиотек, но плохо подходит для сборки приложений. Однако время идет, продукт активно развивается.

Я впервые попробовал его в начале 2017 года. Он сразу понравился мне за поддержку компиляции в ES2015, treeshaking, отсутствием модулей в сборке и конечно простым конфигом. Но тогда это был сырой продукт, с небольшим числом плагинов и очень ограниченной функциональностью, и я решил оставить его на потом и продолжил собирать через browserify. Вторая попытка была в 2018 году, тогда он уже значительно оброс комьюнити, плагинами и функционалом, но все еще не хватало качества в некоторых функциях, включая watcher. И вот наконец в начале 2019 года можно смело сказать — с помощью Rollup можно просто и удобно собирать современные приложения.

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

Сложилось так, что потребовалось контролировать около 30 VDS-ок на Debian, которые мне благополучно «передали» под надзор (а я как бы больше программист, чем *nix-администратор). И первая мысль, что пришла в голову после базовых операций по смене и проверке доступов, была «Если я что-то упустил, хочу оперативно знать о подключениях». Есть рецепты (в том числе на Хабре) связывания события авторизации по SSH и почтовых уведомлений, которые я использовал как базу, но мне хотелось все-таки оперативности и некоторой информативности. В общем получил я в итоге вот такую «систему», которая в течение месяца вполне успешно работает и сообщает мне о любом факте авторизации.

1. С помощью мануалов по API-телеграм получен токен и чат-ид для бота уведомлений (тут распространяться не буду, это все легко и просто находится в 1-2 строке поисковика).
2. Создано два скрипта, код от которых будет размещен ниже. В принципе можно все сунуть и в один файл, но т.к. я хотел модульности, то я вынес в отдельный скрипт функцию отправки уведомления в телеграм-бота.
3. В два файла настроек добавил вызов скрипта регистрации события входа на сервер и перезапустил службу SSH.

На все про все уходит минут 5-10, не больше. Ну а теперь собственно техничка.

PS. Все выполнялось на Debian9 x 64 (если это важно).

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

На конференции HolyJS доклад об опыте использования WebAssembly получил высокие оценки зрителей, и теперь специально для Хабра подготовлена текстовая версия этого доклада (видеозапись также приложена).

Предисловие

Мое веб-приложение хранит данные в localStorage. Это было удобно, пока не захотелось, чтобы пользователь, заходя на сайт с разных устройств, видел одно и то же. То есть, понадобилось удаленное хранилище.

Но приложение «хостится» на GitHub Pages и не имеет серверной части. Я решил не делать сервер, а данные хранить у третьей стороны. Это дает существенные преимущества:

1. Не нужно платить за сервер, не болит голова о его стабильности и доступности.
2. Меньше кода, меньше ошибок.
3. Пользователю не нужно регистрироваться в моем приложении (это многих раздражает).
4. Приватность выше, и пользователь знает, что его данные хранятся в месте, которому он, скорее всего, доверяет больше, чем мне.

Сначала выбор пал на remoteStorage.js. Они предлагают открытый протокол обмена данными, достаточно приятное API, возможность интеграции с Google Drive и Dropbox, а также свои сервера. Но этот путь оказался тупиковым (почему — отдельная история).

В итоге решил использовать Google Drive напрямую, и Google API Client Library (далее GAPI) как библиотеку для доступа к нему.

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

Надеюсь, данная статья сэкономит вам время, если вы решите использовать Google Drive в вашем приложении.

При работе с полигональными ассетами можно отрисовывать только по одному объекту за раз (если не учитывать такие приёмы, как batching и instancing), но если использовать поля расстояний со знаком (signed distance fields, SDF), то мы не этим не ограничены. Если две позиции имеют одинаковую координату, то функции расстояний со знаком возвратят одинаковое значение, и за одно вычисление мы можем получить несколько фигур. Чтобы понять, как преобразовывать пространство, используемое для генерации полей расстояний со знаком, я рекомендую разобраться, как создавать фигуры с помощью функций расстояний со знаком и комбинировать sdf-фигуры.

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

Это мой рабочий стол. Пить пиво в рабочее время у нас разрешено, мы же в Германии.

Моя первая статья: «IT-эмиграция с семьей. И особенности поиска работы в маленьком городе Германии, когда ты уже там»

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

Не умаляя достоинства этих систем, хотелось бы рассказать о том, какие возможности есть у Mediawiki в роли корпоративной базы знаний. Само собой, mediawiki подойдет не всем — в ней нет модной интеграции с jira/tfs/etc, перенос документов с картинками из пакета Microsoft Office доставляет кучу неудобств, да и сама она написана на PHP, что в последнее время служит отпугивающим фактором для некоторых айтишников. Тем не менее, платформа живее всех живых и над ее развитием работает изрядное количество людей, коль скоро на ней базируется семейство проектов фонда Викимедиа.

Те, кто давно занимается поисковой оптимизацией, хорошо знают об операторах расширенного поиска Google. Например, почти все знают об операторе site:, который ограничивает поисковую выдачу одним сайтом.

Большинство операторов легко запомнить, это короткие команды. Но уметь эффективно их использовать — совсем другая история. Многие специалисты знают основы, но немногие по-настоящему овладели этими командами.

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

Какое отношение к легаси-коду имеют «Звёздные войны», группа «Тату» и сочетание «Ctrl-Alt-Del»? Как быть, когда приходишь в большой проект и сталкиваешься с пропастью непонятного старого кода? И как эффективнее донести до начальства, что трудозатраты на ликвидацию технического долга оправдывают себя?

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

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

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


Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.

Содержание

• 1. Антипаттерны: плохое обоснование
  
  • 1.1. Очевидно же
  • 1.2. Мамой клянусь!
  • 1.3. Зайчики обиделись
• 2. Хорошие паттерны обоснования
  
  • 2.1. Пруфлинк
    
    • Ссылка на требования
    • Сами требования
    • Ссылка в интернет
    • Письмо заказчика
    • ROI
    • Статистика
  • 2.2. Единообразие
  • 2.3. Проблема, или #жизньболь
• 3. Когда обоснование не нужно
• 4. Итоги

Когда вы заводите задачу, ее нужно обосновать. Вы должны убедить разработчика, что:

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

А то иногда читаешь баги (особенно баги новичков) и задаешься вопросом:

— Почему это баг??

Например, там написано: «Загружаем отчет, получаем 57,6. А должно быть — 57.9».



Если записать обоснование, это решит проблемы:

• Коллеги отвлекают с вопросами «А почему это баг?», вырывая из контекста.
• Спустя месяц ты сам забыл, а, собственно, почему это был баг…

См также:
Зачем нужно обоснование в баге — более подробно о том, зачем вообще обоснование.

Через меня прошли сотни начинающих тестировщиков (студентов). Вот как раз на их задачах я и начала задаваться вопросом «А почему это баг?»… Спрашиваешь ребят, а в ответ получаешь «Да это же очевидно!». Ну как-то не очень =))

Через кучу задач и вопросов «А почему?» стали вырисовываться паттерны ответов. Я выделила хорошие и плохие паттерны. О них и хочу рассказать.

Эта статья для:

• начинающих тестировщиков — узнайте, как грамотно объяснять свою точку зрения;
• тест-менеджеров — чтобы дать ссылку своим падаванам и потом ссылаться на антипаттерны без дополнительных объяснений.

1. Антипаттерны: плохое обоснование

Наш склад размером с две Красные площади и высотой в 5 этажей работает круглый год и никогда не спит — 24/7 364 дня в году (единственный выходной — 1 января). У нас хранится и обслуживается более 8 000 000 товаров, каждый день на смену выходит более 300 операторов. Они работают с товаром, поступающим со всего мира, и собирают заказы для пользователей из четырех стран: России, Украины, Белоруссии и Казахстана. На таких масштабах бизнес требует безупречной автоматизации.

Под катом я, Паша Финкельштейн — тимлид команды разработки и автоматизации склада — расскажу, во что может вырасти open source решение, если к нему приложить хорошую команду разработки и вполне конкретную бизнес-задачу.

Мы в X5 обрабатываем много данных в ERP-системе. Есть мнение, что больше нас в SAP ERP и SAP BW в России не обрабатывает никто. Но есть еще один момент – число операций и нагрузка на эту систему увеличивается быстро. 3 года мы «сражались» за производительность нашего ERP-тяжеловеса, набили немало шишек, а какими методами их лечили, рассказываем под катом.

Адаптировано из нашей будущей книги «Рефакторинг UI»

Видели эти модные генераторы цветовой палитры? Когда выбираешь цвет, настраиваешь несколько параметров с музыкальными словечками типа «триада» или «четвёртый мажор» — и получаете пять идеальных цветов для своего веб-сайта?



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

Я всегда хотел написать подробное руководство для начинающих о том, как создать roguelike, содержащее как общие, так и более специфические советы. Проведённый в этом году очередной праздник Roguelike Celebration показался мне отличной возможностью наконец-то заставить себя это сделать, поэтому я подготовил получасовой доклад по этой теме.

У меня есть довольно большой опыт — в течение последних семи лет я работал только в этом жанре (Cogmind, Cogmind 7DRL, POLYBOT-7, REXPaint, X@COM), и в течение последних пяти эта работа была моей основной. К тому же, все эти годы я помогал превращению r/RoguelikeDev в крупнейшее сетевое сообщество разработчиков roguelike.

Написал Стивен Тови в 2:29 утра по программированию (шутка юмора Google Translate)
Вступление от себя: эта заметка, прорекламированная Алёной C++, предназначена в основном разработчикам игр для консолей, но будет, наверное, полезна и всем, кому приходится сталкиваться с экстремальным аллоцированием динамической памяти. Возможно, любители посравнивать управление памятью в C++ и Java тоже найдут над чем задуматься.

Оригинал с небезынтересной дискуссией в комментариях: altdevblogaday.org/2011/02/12/alternatives-to-malloc-and-new

Обязательная вступительная басня

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

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



В преддверии нашего курса Go Workshop рассказываем, что психологи, лингвисты и педагоги думают о влиянии кодинга на мозг, при чем тут австралийские индейцы и гипотеза Сепира-Уорфа.