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

Задача — создание и поддержание еженедельного расписания, такого как расписание уроков в школе или расписание работы врачей и чиновников. Имеется набор слотов, каждый слот — это место в недельном расписании с различными дополнительными параметрами, такими как номер кабинета, имя сотрудника. Требуется построить гибкую систему с полной историей, способную решать задачи типа: создать другое расписание с начала лета, заменить учителя на ближайшие 3 недели, передвинуть расписание с пятницы на субботу из-за праздника.

Напишу, обо что обычно спотыкаются и как это решить, решу задачку о закрашивании полоски, а затем приведу примеры простого бэкенда на node/sequelize и закончу несложным фронтендом на vue/vuex/vuetify/nuxt, где можно будет все это потаскать мышкой и посмотреть, как работает.

Коды выложены на github, развернуто здесь.

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

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

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

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

В марте Яндекс запустил бета-тестирование платформы Яндекс.Диалоги. Теперь на её основе можно создать собственный «навык» для голосового помощника Алисы.

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

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

Я играю в Heroes of Might and Magic со времен царя Гороха королевы Ламанды, и за это время накопилось такое количество карт для 3-х Героев, что я решил их как-то упорядочить и структурировать.

Цели были следующие:

1. Избавиться от дубликатов карт
2. Точно знать, играл я в эту карту или нет, если играл, то знать статус: выиграл, проиграл или пропустил
3. Иметь возможность загружать в органайзер новые карты с проверкой на уникальность
4. Писать свой личный комментарий к карте
5. Иметь возможность мгновенно отсортировать каталог карт по следующим параметрам:
   названию, статусу, версии, кодировке, размеру карты, наличию подземелья, уровню сложности и размеру файла
   

DevConf 2018 уже на следующей неделе! В прошлом году Юрий Насретдинов провел интересный обзор перспективных систем хранения данных для highload. Видео с докладом доступно на странице доклада. А для хабра-читателей предлагаю краткий пересказ.

В начале расскажу как нужно подходить к выбору технологии для highload-проекта.

• В первую очередь, должно быть понимание как оно работает. Не только сильные, но и слабые стороны.
• Знание как это мониторить и бэкапить. Без хороших инструментов для этого, эту технологию рано использовать в продакшене.
• Рано или поздно системы «падают»(это нормальная, штатная ситуация) и нужно знать что делать в этом случае.

Общий принцип — Не делай брак.
Не бери брак. Не передавай брак.
Тойота.

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

«Почти» по сетке

Сетка призвана упрощать вёрстку и определять местоположение ключевых элементов. В некоторых случаях дизайнеры намеренно отходят от 12-колоночного грида для создания неординарного дизайна.

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

 
Исследователь Tom Anthony обнаружил сверхкритичную уязвимость в поисковом механизме Google, способную влиять на поисковую выдачу. Компания «исправляла» уязвимость полгода и выплатила за нее всего лишь $ 1337.

В материале, перевод которого мы публикуем сегодня, речь пойдёт о создании мобильных приложений на базе существующих веб-проектов. Автор этой статьи демонстрирует инструменты, которые позволяют с минимальными усилиями разрабатывать приложения, пользующиеся нативными возможностями платформ iOS и Android и включающие в себя материалы работающих сайтов или локальные ресурсы. Его рассказ начинается с тех самых семи строк JSON-кода, которые позволяют превращать сайты в мобильные приложения.


Превращение веб-сайта в мобильное приложение

Под моим надзором примерно 1000 железных серверов, VPS даже не начинаю считать. Пару десятков из них обладают весьма критичными данными. И банальный ssh с ключами в стандартной ситуации не достаточно безопасен. Не все «кожаные люди» берегут ключи, поговорим как защититься от возможности потери ключа пользователем.

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

Предварительный запуск до монетизации

После ухода этим летом с наших прежних работ в корпорациях Эрик (мой соучредитель) и я в конце сентября начали создавать Kapwing. Мы выпустили пилотный проект в середине октября 2017 года. Сначала у нас не было стратегии монетизации. Мы попросили пользователей присылать «пожертвования» Kapwing. Неудивительно, что этого не сделал никто.

В первой статье мы рассказали про наш первый опыт в маркетинге и продажах. В этой статье мы расскажем, почему маркетингом и продажами нужно заниматься самим, даже если вы всю жизнь изучали математику и программирование, а не полагаться на «гуру» с рынка, и какие минимальные действия в области маркетинга и продаж должна сделать компания-разработчик заказного ПО в наше время, чтобы быть прибыльной компанией и иметь возможность устойчиво развиваться. В этой статье не будет затронута тема раскрутки и продажи продуктов, мобильных приложений, игр и многого другого, так как опыт компании Maxilect в основном связан с заказной разработкой, и только в конце 2017 мы начали делать свои R&D разработки и вести работу со стартапами по модели Revenue Sharing.

Рассказ моего партнера Кирилла Антонова, который написал первую часть статьи, остановился примерно в конце 2016 — начале 2017 года. На тот момент мы уже успели наломать немало дров, наступили не на одни грабли, добились первых успехов, и пребывали в некоторой эйфории от того, что наконец-то начало получаться, мы росли, увеличивалась и прибыль, и пора было подумать о динамичном развитии в правильном направлении.

Добрый день, вечер или ночь, все зависит от времени суток в который вам довелось прочитать мою статью.

В связи с ростом количества корпоративных клиентов, было принято решение дать доступ к учетной системе внешним пользователям. Для самостоятельного оформления заказов и отслеживания их состояний. Реализация была создан web интерфейс с необходимым функционалом и доступом. Тут же стал вопрос безопасности, кроме стандартных пользователь-пароль было решено еще усилить безопасность, для этого применили OpenVPN, но появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и.д.), тут на глаза попались статьи про доступ по ssl сертификату.

Глеб Летушов, редактор-фрилансер, адаптировал для блога Нетологии чеклист с Github от David Dias. Этот чеклист уже переводили, но так как на Хабре его нет, мы решили, что он пригодится. В чеклисте собран полный список элементов, которые необходимо проверить перед запуском и публикацией сайта.



Список основан на многолетнем опыте фронтенд-разработчиков, а дополнения собраны из общедоступных источников.

Всем привет! Зовут меня Дмитрий Григоров. Работаю фронтедером в Райффайзенбанке в команде RBO PRO. Я расскажу и покажу вам, как можно творчески применять данные возможности CSS. В статье мы рассмотрим следующие темы:

• Фоны и рамки;
• Фигуры;
• Визуальные эффекты.

Robots.txt указывает веб-краулерам мира, какие файлы можно или нельзя скачивать с сервера. Он как первый сторож в интернете — не блокирует запросы, а просит не делать их. Интересно, что файлы robots.txt проявляют предположения веб-мастеров, как автоматизированным процессам следует работать с сайтом. Хотя бот легко может их игнорировать, но они указывают идеализированное поведение, как следует действовать краулеру.

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

Я взял список 1 млн крупнейших сайтов от Alexa и написал маленькую программу для скачивания файла robots.txt с каждого домена. После скачивания всех данных я пропустил каждый файл через питоновский пакет urllib.robotparser и начал изучать результаты.


^{Найдено в yangteacher.ru/robots.txt}

Список лучших инструментов для web-анимации. SVG/CSS/Canvas/DOM анимация + GUI инструменты для генерации кривых Безье и CSS анимации.

Репозиторий: github.com/sergey-pimenov/awesome-web-animation
Страница-каталог: awesome-web-animation.netlify.app

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

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

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

Напомню, кластер будет размещаться на площадке хостера, логи будут собираться со всего мира по TCP, а среднее количество логов — около 1,2 Тб/день при нормальных условиях.

В настоящее время мы используем CentOS 7 и Graylog 2.2, поэтому все конфигурации и опции будут описываться исключительно для этих версий (в Graylog 2.2 и Graylog 2.3 ряд опций отличается).

Эта статья также есть на английском.

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

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

Под катом — дюжина приемов в командной строке — из личного опыта.

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

Ниже перечисленные принципы выполняются в среде позиционирования элементов на странице. В элементах декора тоже выполняются. Но не так категорично.