Одноразовые беспилотники из бумаги

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

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

Как сообщают враждебные голоса из ближайшей розетки, в рамках гранта DARPA сумрачные калифорнийские гении (из базирующейся в Сан-Франциско компании Otherlab), строили-строили и наконец-то построили прототипы беспилотников из картона, которые, по их хитрому замыслу, предназначены для доставки медикаментов, батарей и устройств связи в опасные или труднодоступные места. На этом месте я почему-то вспомнил близлежащий авиамодельный кружок.
По мысли авторов одноразовые планеры предварительно программируются с указанием места их окончательного упокоения, затем (в обстановке мрачной торжественности) запускаются с борта грузового самолёта или другого летательного аппарата (в ходе испытательных полётов, например, один такой дрон был запущен с беспилотника большего размера) на головы страждущих внизу. После чего под управлением небольшой бортовой системы управления дроны устремляются в свой последний путь. При этом, поскольку это планеры, нет необходимости в размещении на них какой-либо силовой установки, большого аккумулятора или бака с топливом. Максимум внутренних объёмов аппарата, отводится под размещение полезной нагрузки.

К слову, дронами уже доставлены пакеты для платежеспособных клиентов Amazon и лекарства в отдаленные районы Руанды. Министерство обороны США, в свою очередь, тестирует (помимо дедушек терминаторов, порождённых в недрах Boston Dynamics) рои из беспилотников для целого ряда предполагаемых миссий. Но идея полностью одноразовых, распадающихся беспилотных летательных аппаратов пока что воспринимается массами в новинку.

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

Star Simpson, инженерных дел мастерица из Otherlab, говорит, что картон используется только для доказательства работоспособности идеи. Основная же задача состоит в том, чтобы в конечном итоге сделать корпуса дронов из волокон мицелия, то есть грибов. Как она сообщила в интервью одному сетевому журналу про вся, что летает

«Наша предварительная работа в этом направлении показала, что вы можете в массе пропитать [мицелий] различными типами спор [которые] активируются непосредственно перед запуском аппарата.»

Споры будут расти и в буквальном смысле съедят дрон, прогрызая его корпус в течение примерно пяти или шести дней. Тут я поймал себя на мысли, что споры грибов похоже прорастают не только на дронах Otherlab. Что же касается авионики дронов, в DARPA финансирует отдельную, хорошо дополняющую разработки одноразовых дронов, программу развития саморазрушающейся электроники. Чтоб терминаторам не пришлось самоутопляться в расплавленном металле.
Otherlab не привыкать заниматься странными идеями: они известны тем, что возятся со всем, от возобновляемых источников энергии до надувных роботов меня опять посетила мысль про грибы. Из пресс-релиза проекта одноразовых дронов, можно предположить, что С-130 «Геркулес» есть такой у лютых друзей РФ военно-транспортный самолет сможет выпустить за один свой вылёт сотни беспилотных летательных аппаратов с грузами снабжения на борту над пространством размером с Калифорнию.

Пока что команда Otherlab испытывает модели, способные нести на борту полезную нагрузку до одного килограмма, но трепещите! Simpson заявляет, что они могли бы увеличить конструкцию, чтобы сделать беспилотник с размахом крыла в восемь футов (то бишь 2,44 метра), способный перевозить до 10 килограммов полезной нагрузки. Наркокартели уже заинтересованно смотрят на такой аппарат.

Автор текста (вольно мною пересказанного с английского языка): Майкл Рейли

Tails в версии 3.0 откажется от 32 битной архитектуры

Tails в версии 3.0 откажется от 32 битной архитектуры
Разработчики

Tails

приняли решение о том, что примерно с июня 2017 года, начиная с версии 3.0, откажутся от 32 разрядной архитектуры. Аргументировав это двумя причинами: сделать дистрибутив более безопасным и сохранить предыдущие наработки. Они утверждаю, что проанализировали информацию накопленную их системой сообщения об ошибках WhisperBack. И с начала 2016 года, только 4{33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a} пользователей работали в 32 разрядной версии Tails, поэтому исправление ошибок совместимости не стоит их усилий.

«Tails использует 64-разрядное ядро ​​Linux, на машинах, которые поддерживают его ,» говорится в анонсе, — «Но все другие программы, включенные в Tails до сих пор были собраны для 32-битных процессоров, и приходилось решать проблемы совместимости».

Так же сообщают, что 64-разрядные системы имеют лучшую

ASLR

и обязательную поддержку

NX bit

.

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

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

Tails 3.0 в настоящее время находится на стадии бета-версии. В самый последний выпуск включены исправления безопасности:
отклонение пакетов в локальной сети, отправленные NetBIOS;
позволяющее

Seahorse

управлять скрытым пулом Tor OnionBalance .

В конце января, стабильная версия Tails была обновлена ​​с 2.9.1 до 2.10. Как следует из анонса сопутствующего обновлению, был исправлен ряд ошибок:

  • безопасности в браузере Tor; BIND 9;
  • электронной почты клиента Icedove;
  • в работе PCSC-lite смарт-карты;
  • в libgd2 и libxml2 библиотеки;
  • SAMBA;
  • переполнения буфера в клиенте Tor.

5 повседневных продуктов и услуг, готовых к внедрению ИИ

5 повседневных продуктов и услуг, готовых к внедрению ИИ
Что, если бы искусственный интеллект уже присутствовал в нашей жизни?

Технологии, обрабатывающие информацию так, как это делают люди, все еще находятся на ранней стадии развития. Она находит свое применение в виде чат-ботов и голосовых сервисов, подобных Amazon Echo. Тем не менее, многие из услуг, которыми мы пользуемся ежедневно все еще не обладают ИИ, к сожалению. Конечно, умные автомобили или интеллектуальные ассистенты — продукты более отдаленного будущего. Но что насчет продуктов и услуг попроще? Помечтаем?

1. Паркинги

Уже имеют место попытки облегчить процесс парковки. Одна из них при содействии Ford. Можно использовать приложение для бронирования и оплаты парковочного места. Но хочется чего-то более продвинутого. Представьте, паркинг под управлением ИИ идентифицирует вашу машину на въезде, проверит вашу учетную карту и выяснит, что вы лояльный клиент, свяжется с вами по громкой связи и препроводит на свободное место, на следующий день покажет видео с вашим Audi на парковке и предложит возможность автоплатежа. На выезде можно было бы проконсультироваться у бота по возникшим вопросам.

2. Веб-браузеры

Какой прок в ИИ для браузера? Это может показаться надуманным, но агент ИИ мог бы отследить, как вы ведете поиск по конкретной теме (например, о новом принтере), и предложить ссылки на лучшие варианты. Он мог бы запомнить сайты для вас — не просто сделать закладки или сохранить их в своей истории, а добавить их в базу знаний. Вам не нужно будет просто искать этот архив — ИИ может напомнить вам о фактах и ​​предложить ссылки. Он может посмотреть, что вы размещаете в социальных сетях и даже попросить не троллить собеседника, как это часто бывает в Twitter. ИИ может помочь нам в управлении вкладками, регулируя их ширину используемых или предложив закрыть те, к которым мы не прикасались со вчерашнего дня.

3. Банкоматы

Молчаливые терминалы могли бы быть намного умнее. Конечно, основная их задача принимать платежи и выдавать деньги со счета. Банкоматы некоторых крупных банков довольно хорошо запоминают параметры, которые обычно используются при проведении операций, например, шаблон коммунальных платежей. ИИ будет знать о вас больше , напоминать вам (если вы включите такую функцию) о счетах, сроки оплаты которых истекают. Главное, что он мог бы использовать биометрические данные, чтобы идентифицировать вас, знать, что вы всегда перечисляете средства на сберегательный счет по определенным датам и предложить это сделать при приближении срока, а также узнать о других привычках, чтобы сделать процесс быстрее и проще.

4. Дорожные развязки

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

5. Офисная мебель

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

Крушение: как компьютеры провоцируют катастрофы — Часть II

Крушение: как компьютеры провоцируют катастрофы - Часть II

Окончание. Начало здесь

Эрл Винер, культовая фигура в области авиационной безопасности, открыл то, что известно сейчас как Законы Винера об авиации и человеческих ошибках. Один из них звучит так: «Цифровые устройства корректируют малые ошибки провоцируя большие.» Можно перефразировать его так: «Автоматизация призвана приводить в порядок обыкновенные беспорядки, но порою создает необыкновенный беспорядок.» Применение такого определения возможно далеко за рамками авиации.

Виктор Хенкинс, гражданин Великобритании, получил неприятный подарок на Рождество: штраф за парковку в неположенном месте. Хенкинс узнал о штрафе из письма местной администрации, брошенного на придверный коврик его дома. В 20.08 20 декабря 2013 года его автомобиль был блокирован возле автобусной остановки в Брэдфорде графства Йоркшир, и был сфотографирован камерой контроля, установленной на проезжающей мимо машине инспекции. Компьютер определил номерной знак, поискал его в базе данных и нашел адрес мистера Хенкинса. Доказательная база была сформирована автоматически и включала в себя видео происшествия, отметку о времени и местоположении. Письмо администрации Брэдфорда с требованием к Хенкинсу заплатить штраф во избежание судебного иска было составлено, запечатано и отправлено по почте в автоматическом режиме.

Правда, была одна проблема. Машина Хенкинса вообще не была припаркована. Он просто застрял в пробке.

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

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

Чем реже возникают исключения, как в случае с ЭДСУ, тем большие трудности они за собой влекут. Мы исходим из того, что компьютер всегда прав. И когда кто-то говорит, что компьютер сделал ошибку, мы думаем, что он либо сам ошибается, либо лжет. Что происходит, когда частные охранники вышвыривают вас из местного торгового центра, потому что компьютер ошибочно распознал ваше лицо и принял за известного магазинного воришку? (Эта технология сейчас откорректирована, давая возможность ритейлерам распознавать нужных клиентов, чтобы сделать им специальные предложения, когда те приходят в магазин.) Если ваше имя ошибочно попадет в розыскной список полиции, легко ли будет его оттуда исключить?

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

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

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

Эксперты в вопросах принятия решений, такие как Клейн сетуют, что многие разработчики программного обеспечения усугубляют проблему еще больше, намеренно проектируя системы на вытеснение человеческого опыта. Если мы все же захотим использовать спроектированные таким образом системы именно для поддержки человеческого опыта, нам приходится буквально с ними бороться. GPS устройства, например, могут обеспечить все виды поддержки принятия решений, давая возможность водителю просматривать карты и выбирать маршрут. Но эти функции часто спрятаны глубоко в недрах приложений. Нужно приложить усилия, чтобы до них добраться. Зато можно просто нажать кнопку «Начать навигацию» и доверить компьютеру сделать все остальное.

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

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

Радж Раджкумар, эксперт Университета Карнеги-Меллона в области автоматического управления, полагает, что полностью автономные автомобили появятся лет через 10-20. До тех пор, можно рассчитывать лишь на то, что автомобили будут передвигаться под управлением автопилота только в легких ситуациях, а люди будут брать управления на себя лишь в момент возникновения сложных ситуаций.

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

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

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

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

И когда компьютер решит передать управление человеку, он вполне возможно сделает это при наступлении самых экстремальных и сложных условий. У пилотов Air France было 2-3 минуты, чтобы понять, что делать, когда автопилот их А330 отключился. Много ли шансов отреагировать у вас будет, когда компьютер в вашем автомобиле скажет, «Автоматический режим отключен», и вы, оторвавшись от экрана своего смартфона, увидите автобус, мчащийся вам наперерез?

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

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

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

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

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

Делаем глобальное меню в Plasma 5.9

Делаем глобальное меню в Plasma 5.9
Вот и дождались любители

KDE

выхода Plasma 5.9, в котором появилось долгожданное многими global menu. Вне зависимости от того, на Ubuntu вы, OpenSuse, Fedora или нормальном дистрибутиве, рецепт добавления глобального меню будет одинаков и прост. Если вы не смогли найти его в своём дистре интуитивно — добро пожаловать.

Перво-наперво необходимо добавить панель, которая в русской локализации у меня в Manjaro Linux называется «Строка меню приложения», вызвав на рабочем столе контекстное меню как на скриншоте:
Делаем глобальное меню в Plasma 5.9

После чего переходим в «Параметры системы — Оформление приложений — Стиль интерфейса», переходим на вкладку «Тонкая настройка» и меняем параметр «Расположение строки меню» в положение Виджет «Меню приложения» как на скриншоте:
Делаем глобальное меню в Plasma 5.9

Нажимаем кнопку «Применить», перезагружаем иксы комбинацией клавиш «Ctrl+Alt+BackSpace» и получаем желаемое.

Помимо глобального меню, появилась возможность замены стандартной панели меню, на кнопку меню типа «сэндвич». Для этого переходим в «Параметры системы — Оформление приложений — Стиль интерфейса», переходим на вкладку «Тонкая настройка» и меняем параметр «Расположение строки меню» в положение «Кнопка на заголовке окна». Далее здесь же переходим на «Оформление окон» вкладка «Кнопки» и перетаскиваем кнопку Меню в нужное вам место. Выглядит это как на скрине:

Делаем глобальное меню в Plasma 5.9

К сожалению еще не все темы оформления окна поддерживают отображение этой кнопки. Так например моя любимая тема Arc-dark, портированная Алексеем Варфоломеевым ака Varlesh, пока не адаптирована к новому функционалу. И хотя Алексей больше не поддерживает этот порт, надеюсь что найдутся умельцы которым это по силам. Лично для меня Arc-dark это самая лучшая тема в KDE 5, только в ней моим глазам комфортно сидеть часами за монитором.

Если вам интересны подобные туториалы и мануалы по Linux пишите в комментариях.

10 лучших редакторов с поддержкой Markdown для Linux

10 лучших редакторов с поддержкой Markdown для Linux

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

Markdown (маркдаун) — это облегчённый язык разметки, созданный с целью написания максимально читаемого и удобного для правки текста, но пригодного для преобразования в языки для продвинутых публикаций (HTML, Rich Text и др.).

Atom

Atom это современный, кроссплатформенный, мощный текстовый редактор с открытым исходным кодом, работающий в Linux, Windows и Mac OS X. Он очень хорошо настраивается, в том числе благодаря плагинам.

В число его преимуществ входят следующие:

  • Встроенный менеджер пакетов (плагины, темы и т.п.)
  • Умное автодополнение кода
  • Поддержка разделения окна
  • Поиск и замена текста
  • Встроенный диспетчер файлов
  • Настраиваемые темы
  • Легко расширяем с помощью плагинов с открытым исходным кодом

Домашняя страница: https://atom.io/

VS Code

Всё, описанное для предыдущего приложения, справедливо и для Visual Studio Code. Это удобный и мощный редактор с открытым исходным кодом, расширяемый с помощью плагинов и с поддержкой тем оформления. Имеет встроенный отладчик и клиент системы контроля версий. Работает с Markdown также с помощью удобного плагина, сразу показывая результат в соседнем окне.

Домашняя страница: https://code.visualstudio.com

GNU Emacs

Кто не знает Emacs? Этому редактору уже более 40 лет и он считается одним из самых популярных приложений под *nix системы.

Важные функции:

  • Встроенная документация и учебник для новичков
  • Полная поддержка Unicode
  • Различные режимы редактирования текста, настроить редактор под себя несложно
  • Подсветка синтаксиса для большинства типов файлов
  • Хорошо настраивается на Emacs Lisp или через GUI
  • Есть система пакетов для загрузки и установки, огромное сообщество и еще много всего…

10 лучших редакторов с поддержкой Markdown для Linux

Домашняя страница: https://www.gnu.org/software/emacs/

Remarkable

Remarkable, возможно, лучший из перечисленных редактор Markdown для Linux. Он поддерживает полный синтаксис Markdown и чрезвычайно функционален:

  • Предпросмотр в реальном времени
  • Экспорт в PDF и HTML
  • Поддержка Github Markdown
  • Поддержка своих стилей CSS
  • Подсветка синтаксиса с автоматическим определением языка
  • Горячие клавиши

10 лучших редакторов с поддержкой Markdown для Linux

Домашняя страница: https://remarkableapp.github.io

ReText

ReText это простой, лёгкий и мощный редактор Markdown для Linux. Обладает следующими функциями:

  • Простой и интуитивный GUI
  • Очень настраиваемый
  • Поддержка цветовых схем
  • Поддержка математических формул
  • Есть расширения для экспорта текста и многое другое…

10 лучших редакторов с поддержкой Markdown для Linux

Домашняя страница: https://github.com/retext-project/retext

Mark My Words

Mark My Words это также лёгкий, но мощный редактор Markdown. Он относительно молодой, но обладает многими важными функциями, включая подсветку синтаксиса, простой и удобный GUI.

  • Предпросмотр в реальном времени
  • Экспорт в PDF и HTML
  • Слежение за изменениями файлов во внешней программе

10 лучших редакторов с поддержкой Markdown для Linux

Домашняя страница: https://github.com/voldyman/MarkMyWords

Vim-Instant-Markdown Plugin

Vim это очень популярный и мощный текстовый редактор под Linux, также проверенный временем. Он очень любим программистами за гибкость, лёгкость и расширяемость.

Для Vim есть несколько плагинов для поддержки Markdown, попробуйте наиболее эффективный из них Vim-Instant-Markdown.

Домашняя страница: https://github.com/suan/vim-instant-markdown

SublimeText-Markdown плагин

Sublime Text очень популярен и не нуждается в представлении. Для поддержки в нём Markdown рекомендую плагин SublimeText-Markdown, он имеет отличную подсветку синтаксиса, выбор цветовых схем и многое другое.

10 лучших редакторов с поддержкой Markdown для Linux

Typora

Typora не имеет окна предпросмотра, переключателя режима и всего такого. В ней всего одно окно с подсветкой синтаксиса Markdown в реальном времени, чтобы вас ничто не отвлекало от текста.

Основные возможности:

  • Поддержка Markdown, включая таблицы, блоки кода с подсветкой, LaTeX, Оглавления.
  • Кроссплатформенность
  • Красивый интерфейс и поддержка своих CSS стилей.
  • Удобный экспорт заметок

Домашняя страница: https://typora.io/

Надеюсь, с этим списком вы выберете себе удобный редактор по вкусу!

На сайте наших друзей вышла статья на эту тему, так же рекомендую её к ознакомлению https://gitjournal.tech/

Если у вас есть свои предложения по теме, предлагаю обсудить их в комментариях 🙂

Построение Morphing Hamburger Menu только на CSS

Недавно я наткнулся на dribbble Виталия Рубцова, и я не смог устоять перед желанием реализовать его Morphing Hamburger Menu исключительно на CSS. Это меню легко можно использовать при создании дизайна интерфейса мобильных приложений и сайтов.

Построение Morphing Hamburger Menu только на CSS

В этом уроке я покажу весь процесс, как это сделать только с помощью CSS, не используя не единой строчки JavaScript. Вы увидите некоторые трюки CSS (и SCSS), которые позволяют достичь анимации такой же плавной, как анимированный GIF.

Пример из CodePen того что мы будем делать

Начнём с HTML. Для понимания что для чего читайте комментарии.

Теперь добавляем базовые стили для придания необходимого нам внешнего вида.
/* Basic styles */

* {
box-sizing: border-box;
}

html, body {
margin: 0;
}

body {
font-family: sans-serif;
background-color: #F6C390;
}

a {
text-decoration: none;
}

.container {
position: relative;
margin: 35px auto 0;
width: 300px;
height: 534px;
background-color: #533557;
overflow: hidden;
}

Перед тем как начать строить остальную часть интерфейса, давайте добавим функциональные возможности лёгкого переключения из одного состояния в другое. Нужный нам HTML уже на есть, а стиль, чтобы всё работало может быть чем-то вроде этого:
// To hide the checkbox
#toggle {
display: none;
}

// Styles for the 'open' state, if the checkbox is checked
#toggle:checked {
// Any element you need to change the style if menu is open goes here, using the sibling selector (~) as follows

// Styles for the open navigation menu, for example
& ~ .nav {
}
}

Теперь нам нужно преобразовать пункты меню в линии, чтобы создать значок меню гамбургер. Это можно сделать несколькими способами, мы сделаем это так:
Построение Morphing Hamburger Menu только на CSS

И вот код для работы всего что мы задумали:
$transition-duration: 0.5s;

// Showing nav items as lines, making up the hamburger menu icon
.nav-item {
position: relative;
display: inline-block;
float: left;
clear: both;
color: transparent;
font-size: 14px;
letter-spacing: -6.2px;
height: 7px;
line-height: 7px;
text-transform: uppercase;
white-space: nowrap;
transform: scaleY(0.2);
transition: $transition-duration, opacity 1s;

// Adjusting width for the first line
&:nth-child(1) {
letter-spacing: -8px;
}

// Adjusting width for the second line
&:nth-child(2) {
letter-spacing: -7px;
}

// Adjusting from the fourth element onwards
&:nth-child(n + 4) {
letter-spacing: -8px;
margin-top: -7px;
opacity: 0;
}

// Getting the lines for the hamburger menu icon
&:before {
position: absolute;
content: '';
top: 50{33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a};
left: 0;
width: 100{33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a};
height: 2px;
background-color: #EC7263;
transform: translateY(-50{33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}) scaleY(5);
transition: $transition-duration;
}
}

Обратите внимание, что здесь мы разместили только основные стили для элементов nav, которые являются наиболее важной частью. Полный код на GitHub.

Чтобы построить открытое меню нам нужно переделать nav элементы из линий в текстовые ссылки, добавив незначительные изменения. Давайте посмотрим, как это сделать:
$transition-duration: 0.5s;

#toggle:checked {

// Open nav
& ~ .nav {

// Restoring nav items from "lines" in the menu icon
.nav-item {
color: #EC7263;
letter-spacing: 0;
height: 40px;
line-height: 40px;
margin-top: 0;
opacity: 1;
transform: scaleY(1);
transition: $transition-duration, opacity 0.1s;

// Hiding the lines
&:before {
opacity: 0;
}
}
}
}

Если внимательно посмотреть на gif, мы увидим, что элементы меню не двигаются одновременно, а выдвигаются по очереди. Это реализуется тоже с помощью CSS. Мы должны выбрать каждый элемент (с помощью: nth-child) и установить задержку постепенно увеличивая. Но это, конечно, монотонная работа. Вы зададите резонный вопрос: а что если мы имеем больше элементов? Не волнуйтесь, мы можем сделать это лучше добавив немного SCSS-магии:
$items: 4;
$transition-delay: 0.05s;

.nav-item {

// Setting delays for the nav items in close transition
@for $i from 1 through $items {
&:nth-child(#{$i}) {
$delay: ($i - 1) * $transition-delay;
transition-delay: $delay;
&:before {
transition-delay: $delay;
}
}
}
}

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

Обратите внимание, что с помощью этого кода мы получим желаемое ступенчатое поведение для анимации. Нам нужно вычислить $delay для открытия, чтобы получить обратный переход, сделаем это так:
$delay: ($items - $i) * $transition-delay;

Ну и собственно, наше меню готово. Нужно ещё добавить несколько элементов заглушек, как на анимированном gif в начале статьи, результат можно посмотреть в DEMO

Итак, мы смогли сделать крутое функциональное меню, без единой строки js, как и обещали в начале. Если вам не нравится использовать чистый css, всё это вы легко можете заменить несколькими строками JavaScript.

Надеюсь вам оказалась полезна эта статья.

Источник на английском: https://scotch.io/

Крушение: как компьютеры провоцируют катастрофы

Крушение: как компьютеры провоцируют катастрофы
Мы все чаще используем компьютеры в управлении самолетами и во время проверки безопасности. Беспилотные автомобили уже совсем рядом. Но не снижает ли наша зависимость от автоматизации наши собственные навыки до опасного уровня?

Когда сонный Марк Дюбуа вошел в кабину своего самолета, он столкнулся с полной неразберихой. Самолет трясло так сильно, что он с трудом мог разобрать показания приборов. Сигнал тревоги чередовался с голосом автоинформатора: «СВАЛИВАНИЕ». Управление осуществлялось группой вторых пилотов. Дюбуа спокойно спросил: «Что происходит?»

Ответ пилота Дэвида Роберта был не столь спокойным. «Мы полностью потеряли контроль над самолетом, и не можем ничего понять! Мы попробовали все! »

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

Уильям Лэнгвиш, писатель и профессиональный пилот, написал в октябре 2014 года в своей статье для журнала Vanity Fair: Полет рейса 447 авиакомпании Air France начался достаточно стандартно. 31 мая 2009 года самолет вылетел строго по расписанию в 19.29 из Рио-де-Жанейро в Париж. У всех трех пилотов были свои уязвимые места. 32-летний Пьер-Седрик Бонин был относительно молод и неопытен. 37-летний Дэвид Роберт обладал большим опытом, но, став недавно менеджером Air France, летал от случая к случаю. 58-летний капитан Марк Дюбуа имел большой опыт работы, но он летал в Рио в сопровождении стюардессы, у которой в тот день был выходной. Позже было сообщено, что перед полетом он спал всего лишь час.

К счастью, не смотря на все эти потенциальные угрозы, экипаж находился на борту одного из самых современных самолетов в мире, Аэробуса 330, широко известном своей простотой управления. Как и у любого другого современного самолета, у А330 есть автопилот, с помощью которого самолет летит согласно запрограммированному маршруту. Но кроме того, в нем есть и гораздо более сложная система автоматизации под названием Электродистанционная система управления (ЭДСУ). В обычном самолете пилот обладает полным контролем его органов управления — руля направления, руля высоты и элеронов. Это означает, что пилоту легко допустить ошибку в управлении. Использование ЭДСУ делает пилотирование более безопасным. Она является прослойкой между пилотом, со всеми его возможными ошибками, и механикой самолета. Деликатный переводчик между человеком и машиной, он улавливает каждое движение пилота ручкой управления и определяет намерения пилота относительно движения самолета и выполняет этот маневр безукоризненно, превращая неуклюжие движения в грациозные.

Благодаря всему этому довольно трудно разбить А330. Уровень безопасности самолета очень высок. Не было ни одного сбоя в коммерческой эксплуатации в течение 15 лет после его ввода в эксплуатацию в 1994 году. Но, как это ни парадоксально, у самолета есть изъян. Он заключается именно в чрезмерной опеке пилотов. Система защищает пилота даже от малейшей ошибки так усердно, что, когда будет иметь место нечто более сложное, у пилотов не хватит опыта, чтобы справиться с этой задачей.

Условия полета рейса 447 не казались такими уж сложными: гроза над Атлантическим океаном, к северу от экватора. Это не было серьезной проблемой. Хотя, возможно, капитану Дюбуа не стоило покидать кабину в 23.02 по времени Рио-Де-Жанейро, чтобы вздремнуть, доверяя управление неопытному Бонину.

Казалось, Бонин нервничает. Не было ни малейшего намека на неприятности. Тем не менее, он взорвался ругательствами: “Putain la vache. Putain!”, что приблизительно можно перевести как «Твою ж мать!». Несколько раз он хотел подняться на высоту «3-6» — 36 000 футов — и посетовал на то, что летный регламент Air France, рекомендуют более низкую высоту. Преодолеть грозу можно с меньшим ущербом, пролетев над ней. Но существуют объективные ограничения высоты полета. На большой высоте атмосфера становится настолько разреженной, что она едва может удерживать воздушное судно. Ошибиться очень легко. Самолету угрожает сваливание. Самолет сваливается, если пытается подняться слишком круто. На данном угле крылья больше не выполняют свою функцию и самолет больше не ведет себя как самолет. Он теряет скорость полета и падает в положение носом вверх.

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

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

А затем прозвучал сигнал тревоги. Автопилот выключился. Датчик скорости полета самолета обледенел и перестал работать. Это на самом деле не является серьезной проблемой. От пилотов требуется всего лишь вернуть полет под свой контроль. Но кое-что еще произошло в это же время и по этой же причине: ЭДСУ перешел в режим, при котором пилоту оказывается меньшая помощь и предоставляется большая широта действий в управлении самолетом. Без показаний датчика скорости, самолет не был в состоянии опекать Бонина.

Последствия не заставили себя ждать. Самолет начал раскачиваться из стороны в сторону, а Бонин отклонял ручку управления слишком далеко в сторону, пытаясь стабилизировать направление движения. А потом Бонин допустил ошибку: он взял ручку на себя, и самолет стал круто набирать высоту.

Когда нос самолета задрался и стал терять скорость, автоинформатор сообщил по-английски о сваливании. Несмотря на предупреждение, Бонин продолжал тянуть штурвал на себя. И в черном небе над Атлантикой самолет достиг невообразимой скорости 7000 футов в минуту. Но возможность набора высоты самолетом была исчерпана, и он устремился сквозь бурю вниз к воде с высоты 37,5 тысяч футов. Если бы Бонин или Роберт поняли, что происходит, они могли бы устранить проблему, по крайней мере, на ранних стадиях. Но они этого не сделали. Почему?

Источником проблемы была система, которая обеспечивала безопасность А330 в течение 15 лет, миллионы миль полета: ЭДСУ. Точнее, не сама система, а тот факт, что пилоты привыкли полагаться на неё. Бонин запутался. Возможно, он не понимал, что самолет перешел в альтернативный режим, который обеспечиват гораздо меньшую помощь. Возможно, он знал, что самолет переключил режимы, но не смог в полной мере оценить степень своего влияния на управление и то, что теперь он может привести самолет в сваливание. Это наиболее вероятная причина того, почему Бонин и Роберт проигнорировали сигнал тревоги. Они предположили, что в этот момент самолет сообщал им, что ЭДСУ вмешается в управление, чтобы предотвратить сваливание. Короче говоря, Бонин увел самолет в сваливание, потому что подсознательно чувствовал, что это невозможно.

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

Пилоты Air France «были чудовищно некомпетентны», пишет Уильям Лэнгвиш, в своей статье Vanity Fair. И он полагает, что знает, почему. Лэнгвиш утверждал, что пилоты просто не привыкли самостоятельно управлять самолетом на крейсерской высоте без помощи компьютера. Даже опытный капитан Дюбуа не обладал должным уровнем навыков: из 346 часов, проведенных им за штурвалом самолета в течение последних шести месяцев, только четыре приходились на режим ручного управления, и даже тогда это происходило при включенном ЭДСУ. У всех трех пилотов отсутствовала возможность практиковать свои навыки, поскольку самолет, как правило, сам совершал полет.

У этой проблемы есть имя: парадокс автоматизации. Он применяется в самых различных контекстах: от операторов атомных станций до экипажей круизных судов, от простейших случаев, когда мы больше не можем вспомнить телефонные номера, потому что они все хранятся в наших мобильных телефонах, до трудностей возникающих при совершении арифметических действий в уме, потому что нас окружают электронные калькуляторы. Чем совершеннее автоматические системы, тем меньше практических навыков будет у человека, и с тем более экстремальными ситуациями ему придется столкнуться. Психолог Джеймс Причина, автор книги «Человеческая ошибка», писал: «Ручное управление является высококвалифицированной деятельностью, и практикование навыков должно быть постоянным, чтобы их сохранить. Тем не менее, система автоматического управления отказывает операторам в возможности практиковать эти базовые навыки управления … и при переходе системы в ручное управление, как правило, что-то идет не так. Это означает, что операторы должны быть более опытны, чтобы справиться с этими нетипичными задачами.»

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

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

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

Разбуженный по тревоге капитан Дюбуа прибыл в кабину через 1 минуту 38 секунд после того, как датчики скорости полета вышли из строя. Самолет все еще находился выше 35 000 футов, хотя и падал со скоростью 150 футов в секунду. Антиобледенители сделали свою работу, и датчик воздушной скорости снова заработал, но вторые пилоты перестали доверять своим приборам. Самолет — который был теперь в отличном рабочем состоянии — говорил им, что они движуться не вперед, а вниз к воде, опускаясь десятки тысяч футов. Но вместо того, чтобы осознать, что неисправность датчиков была устранена, они по всей видимости, предположили, что остальные приборы также стали выходить из строя. Дюбуа молчал 23 секунды — долгое время, если сосчитать их. Достаточно долго для того, чтобы упасть на 4000 футов.

Но было еще не слишком поздно спасти самолет, если бы Дюбуа был в состоянии осознать, что с ним происходит. Нос поднялся настолько, что предупреждение о сваливании исчезло с табло. Это, по видимому, было воспринято пилотами, как очередная ошибка, и было проигнорировано. Пару раз Бонин попытался опустить нос самолета, и аварийное предупреждение о сваливании вновь появилось, что, несомненно, смутило его еще больше. На одном из этапов он попытался задействовать тормоза скорости, обеспокоеный тем, что они летят слишком быстро. Что было противоположно истине: самолет летел вперед со скоростью менее 60 узлов, около 70 миль в час — слишком медленно. Он падал в два раза быстрее. Окончательно запутавшись, пилоты попытались обсудить, что делает самолет, набирает высоту или снижается.

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

Роберт: «Ваша скорость! Вы поднимаетесь! Снижайтесь! Снижайтесь, снижайтесь, снижайтесь!»

Бонин: «Я снижаюсь!»

Дюбуа: «Нет, вы поднимаетесь.»

Бонин: «Я поднимаюсь? Хорошо, будем снижаться. »

Никто не сказал: «Мы сваливаемся. Опускайте нос вниз и выходите из сваливания.»

В 23.13 и 40 секунд, менее чем через 12 минут после того, как Дюбуа впервые покинул кабину, отправившись спать, и через две минуты после того, как отключился автопилот, Роберт кричал на Бонина: «Поднимайтесь … поднимайтесь… поднимайтесь… поднимайтесь…» Бонин ответил, что он все время держал ручку в положении «На себя» — информация, которая могла бы помочь Дюбуа диагностировать сваливание, если бы он это знал.

Наконец, до Дюбуа, который стоял позади двух вторых пилотов, дошло «Нет, нет, нет … Не поднимай … нет, нет.»

Роберт объявил, что взял под управление на себя и опустил нос самолета вниз. Самолет начал наконец ускоряться. Но он опоздал буквально на минуту — высота 11000 футов над уровнем моря. Места между резким падением самолета и черными водами Атлантики, чтобы восстановить скорость, а затем вытащить из пикирования, было недостаточно.

Так или иначе, Бонин молча вновь взял управление самолетом на себя и опять попытался подняться. Это была чистая паника. Роберт и Дюбуа, возможно, поняли, что самолет сваливался — но они этого не разу не сказали. Они, возможно, не поняли, что Бонин был единственным, кто управлял самолетом. И Бонин так и не понял, что он сделал. Его последние слова были: «Но что происходит?»

Четыре секунды спустя самолет упал в Атлантический океан около 125 миль в час. Все на борту, 228 пассажиров и членов экипажа, погибли мгновенно.

Окончание следует

Пишем cron микросервис с AWS Lambda и Serverless

Недавно мы столкнулись с ситуацией, когда нам понадобилось создать задание cron присоединять всех из нашей базы данных пользователей находящихся в конце своего триального периода, в базу данных customer.io. Задание cron написать легко, сложно его по уму настроить.
Вариантов несколько:

  • можно редактировать /etc/crontab на сервере;
  • если используете heroku, то можно сделать это с помощью их планировщика(Scheduler);
  • или вы можете использовать реализации cron на предпочтительном вам языке программирования.

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

Использовать AWS Lambda/Serverless

AWS Lambda это облачная вычислительная платформа, которая позволяет загрузить какой либо код, и исполнять его в облачном окружении. Прелесть сего метода в том, что платите вы только за время когда ваш код работает(с шагом 100 мс).
В сочетании с АМС ScheduledEvents это стало идеальным решением для нас.

Serverless это фреймворк и утилита командной строки которая упрощает создание функций AWS Lambda через API более удобное, чем официальный модуль узла aws-sdk. Он имеет хорошую документацию для установки, и подробную инструкцию, как дать ему доступ к учетной записи AWS: Инструкция.

Микросервис создается следующими командами (необходимо также установить AWS):
npm i serverless -g
serverless create --template aws-nodejs --path users-ending-trial
cd users-ending-trial

Затем берём файл serverless.yml и добавим опционально время в которое вы намерены выполнять его:
service: users-ending-trial
provider:
name: aws
runtime: nodejs4.3
functions:
fetchTrialUsers:
handler: handler.fetchTrialUsers
events:
# 10am every morning
- schedule: cron(0 10 * * ? *)

Пропишем в handler.js следующее:
'use strict';

const mongo = require('mongodb').MongoClient;

const CUSTOMER_IO_KEY = process.env.CUSTOMER_IO_KEY;
const CUSTOMER_IO_SECRET = process.env.CUSTOMER_IO_SECRET;
const MONGO_READ_URL = process.env.MONGO_READ_URL;

const CustomerIo = require('customerio-node');

const cio = new CustomerIo(CUSTOMER_IO_KEY, CUSTOMER_IO_SECRET);

function getRelativeDate(offset) {
return new Date(new Date().setDate(new Date().getDate() + offset));
}

module.exports.fetchTrialUsers = (event, context, callback) => {
mongo.connect(MONGO_READ_URL, (err, db) => {
db.collection('projects').find({ 'trial.trialEndsAt': { $gt: getRelativeDate(2), $lt: getRelativeDate(4) }, plan: 'free' }).toArray((err, projects) => {
if (err) {
console.error('Error reading projects from database');
return callback(err);
}

Promise.all(projects.map((project) => {
return cio.track(project.owner, { name: 'threeDaysLeft', data: { project } });
})).then(() => {
callback(null, projects.length);
}, (e) => {
console.error('Error tracking customers in customer.io', e);
return callback(e);
});

db.close();
});
});
};

Чтобы тестировать работу локально выполняем:
serverless invoke local -f fetchTrialUsers
Чтобы развернуть в продакшн:
serverless deploy -f fetchTrialUsers
Для запуска используйте ту же команду что и для локального теста, только без local:
serverless invoke -f fetchTrialUsers
И вуаля! Теперь это должно запускать ваш исполняемый код на AWS Lambda каждый день в назначенное время. Этот простой, но очень мощный способ работы, который позволяет сосредоточиться на коде, а не на инфраструктуре, которая требуется для его запуска.

Источник на английском: https://blog.readme.io/

Делаем Python IDE из Vim

Я люблю Vim и зачастую использую его, когда пишу Python-код. Поделюсь с вами несколькими полезными плагинами и утилитами для создания полноценного Python IDE используя Vim 8.

Делаем Python IDE из Vim
Как вы наверное заметили по скриншоту терминала, я так же использую tmux. Считаю его очень удобным.

Проверка синтаксиса

Многие используют syntastic для проверки синтаксиса, но я рекомендую попробовать w0rp/ale(Asynchronous Lint Engine) это плагин для NeoVim и Vim 8, реализующий линтинг, аналогично flycheck в emacs, работает «на лету», вы печатаете — он проверяет.
Делаем Python IDE из Vim

Форматирование кода

Для форматирования python-кода я использую google/yapf. Сделайте привязку клавиш к yapf через =.
autocmd FileType python nnoremap = :0,$!yapf
Можете ещё попробовать Chiel92/vim-autoformat.

Сортировка import

timothycrosley/isort позволяет сортировать в алфавитном порядке import, и автоматически разделяет на секции. Например, используйте i для выполнения isort на вашем текущем файле python:
autocmd FileType python nnoremap i :!isort {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}
Или можете для этого использовать этот Vim плагин: fisadev/vim-isort.

Автодополнение

Valloric/YouCompleteMe отличный вариант автодополнений. Если вы считаете, что YouCompleteMe слишком громоздкий, попробуйте jedi-vim, как альтернативу. Они оба используют jedi в качестве бэкенда .

Делаем Python IDE из Vim
Если вы используете neovim, можете попробовать для этих целей Shougo/deoplete.nvim.

Быстрый запуск

Если вы используете Vim8, то можете асинхронно исполнять файлы с помощью skywind3000/asyncrun.vim и на выходе автоматически получите результат вроде этого:
" Quick run via
nnoremap :call compile_and_run()

augroup SPACEVIM_ASYNCRUN
autocmd!
" Automatically open the quickfix window
autocmd User AsyncRunStart call asyncrun#quickfix_toggle(15, 1)
augroup END

function! s:compile_and_run()
exec 'w'
if &filetype == 'c'
exec "AsyncRun! gcc {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a} -o {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}<; time ./{33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}<" elseif &filetype == 'cpp' exec "AsyncRun! g++ -std=c++11 {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a} -o {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}<; time ./{33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}<" elseif &filetype == 'java' exec "AsyncRun! javac {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}; time java {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}<" elseif &filetype == 'sh' exec "AsyncRun! time bash {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}" elseif &filetype == 'python' exec "AsyncRun! time python {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}" endif endfunction

Для neovim, можете использовать neomake/neomake. Вот описание из README neomake:

Он предназначен для замены встроенной комманды :make и предоставляет функциональные возможности, аналогичные таким плагинам как syntastic и dispatch.vim. В основном используется для запуска кода линтеров и компиляторов из Vim, но может быть использован для запуска любой программы.

Другой, довольно удобный способ, к которому я прибегаю, заключается в использовании Tmux. Идея проста: он разделяет экран эмулятора терминала на две части. В одной из них будет запущен Vim, а в другой, вы запускаете ваши сценарии.
Делаем Python IDE из Vim

Расширяем стандартную подсветку синтаксиса python

Для этой цели используйте python-mode/python-mode. Например, вы можете добавить подсветку для pythonSelf .
hi pythonSelf ctermfg=68 guifg=#5f87d7 cterm=bold gui=bold
Делаем Python IDE из Vim
Если желаете сильнее кастомизировать подсветку, можете использовать space-vim: python Layer и syntax/python.vim in python-mode/python-mode .

На самом деле, python-mode содержит тонны всякого добра для разработки в Vim, например, статический анализ, автодополнения, документация и многое другое. (Но лично я предпочитаю, функциональные возможности сторонних плагинов.)

Подытожим

Есть также необходимые плагины общего программирования, такие как scrooloose/nerdcommenter для удобного комментирования, Yggdroot/indentLine or nathanaelkane/vim-indent-guides для визуального отображения отступов в Vim и другие.

Делаем Python IDE из VimВ целом, vim великолепное приложение и имеет массу отличных плагинов способных облегчить жизнь, потому вопрос выбора IDE для меня не возникает.:)
Можете еще присмотреться к space-vim, активировать ycmd, syntax-checking, python и программируемые слои , на выходе получите тоже что на скриншоте слева.