Перед вами — первый материал из серии, посвящённой разработке полноценного веб-приложения, которое называется Budget Manager. Основные программные средства, которые будут использованы в ходе работы над ним — это Node.js для сервера, Vue.js для фронтенда, и MongoDB в роли базы данных.



Эти материалы рассчитаны на читателей, которые знакомы с JavaScript, имеют общее представление о Node.js, npm и MongoDB, и хотят изучить связку Node-Vue-MongoDB и сопутствующие технологии. Приложение будем писать с нуля, поэтому запаситесь любимым редактором кода. Для того, чтобы не усложнять проект, мы не будем пользоваться Vuex и постараемся сосредоточиться на самом главном, не отвлекаясь на второстепенные вещи.

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

 
Создание iOS-приложения – непростая задача. Разработчикам хочется как можно быстрее завершить этот процесс и наконец запуститься в AppStore. Но на этом все не заканчивается: впереди у создателей долгие годы исправления ошибок, улучшения функций и совместной работы с другими разработчиками. Мы бы хотели немного облегчить им жизнь и для этого решили разобрать три вещи, которые нужно избегать при iOS-разработке (спасибо Envato Tuts+ за информацию).

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

Прим. перев.: Автор статьи Giancarlo Rubio — DevOps-инженер из ИТ-компании LINKIT (Нидерланды) — через онлайн-ресурс ITNEXT делится лаконичным рецептом по настройке мониторинга с Prometheus в Kubernetes с помощью Prometheus Operator. Инструкция появилась как следствие недавнего опыта выбора и внедрения системы проактивного мониторинга после миграции проекта с bare metal на облачную инфраструктуру. Рецепт отлично подходит для быстрого теоретического (первая половина статьи) и практического (вторая половина) знакомства. Для некоторых команд исправлены URL'ы, которые в оригинальном материале, по всей видимости, были преобразованы движком medium.

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

Если тебе интересно машинное обучение, то приглашаю в «Мишин Лернинг» — мой субъективный телеграм-канал об искусстве глубокого обучения, нейронных сетях и новостях из мира искусственного интеллекта.

Вопросы, которые разобраны в статье:

• Как собрать и подготовить данные для построения модели?
• Что такое нейронная сеть и как она устроена?
• Как написать свою нейронную сеть с нуля?
• Как правильно обучить нейронную сеть на имеющихся данных?
• Как интерпретировать модель и ее результаты?
• Как корректно оценить качество модели?

Что бы ни сказал тебе твой дракон, он солгал. Драконы лживы. Ты не знаешь, что ждет тебя на другой стороне.
Майкл Суэнвик. «Дочь железного дракона»

Не так давно на Хабре был опубликован пост под названием "Как может вызваться никогда не вызываемая функция?". Выводы из статьи простые: в случае undefined behaviour компилятор вправе предпринимать любые действия, даже если они будут совершенно неожиданными. Однако меня заинтересовал сам механизм этой оптимизации. Результатом своего небольшого исследования я хочу поделиться с уважаемым сообществом хабра.

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

Вступление

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

Для чего?

Как написано в документации хостинг предназначен для Django, Pylons, Pyramid, Flask, Trac или любых других WSGI-совместимых приложений. Я пока успел попробовать побаловаться с небольшими приложениями на фреймворке bottle.

В этой серии статей Альваро Виделла (соавтор книги «RabbitMQ in Action», предыдущие места работы: Apple, VMWare, EMC) поделится тем, как он попал в мир программирования. Он никогда не изучал IT в университете, но нашел способ обойти это.



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

В моем родном городе Дурасно, Уругвай, моя жена работала часами напролет за жалкие $160 (USD) в месяц. Да, это 1920 $ в год. Мы оба пожертвовали нашим временем, чтобы я смог стать учителем и нашел работу получше, потому что мы мечтали о лучшем будущем.

Введение

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

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

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

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

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

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

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



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

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

Мне поисковики на запросы типа «совмещение труда» выдают в топе всевозможные статьи для кадровиков, объясняющих, каким образом правильно оформить совмещение труда, не нарушая Трудовой кодекс РФ. Мне же хочется в данной статье раскрыть тему с позиции экономики труда, организации производственных отношений, планирования разделения и кооперации труда на предприятии.

После прочтения прошу всех пройти опрос.

Введение

Наверняка некоторые из вас знают, что такое блокчейн Эфириум (с англ. Ethereum), другие, напротив, не имеют даже малейшего представления о нем. Так или иначе, и первые и вторые что-нибудь да слышали о данной платформе. В последнее время этой теме было посвящено множество статей в различных крупных журналах, однако для тех людей, кто мало что слышал об Эфириуме, все статьи на эту тему представляются чем-то мистическим и совершенно непонятным. Тогда, что же собой представляет данная платформа? Если вкратце: Эфириум – это общедоступная база данных с возможностью хранения цифровых транзакций в течение неограниченного времени. Важно также отметить, что для обслуживания и защиты такой базы данных не требуется каких-либо систем управления ключами. Вместо этого данная платформа работает как «беззащитная» транзакционная система – фреймворк, в котором физические лица могут совершать одноранговые транзакции, при этом ни одна из сторон не несет перед другой или третьей сторонами каких-либо обязательств.

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

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

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

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

Теперь мы даем сервисам, которые ведут свои рассылки, возможность защититься от такого рода подделок с помощью технологии DMARC (dmarc.org), которую мы поддержали первыми среди крупных почтовых сервисов в рунете.

В конце 2011 года разработчики проекта dkim-milter прекратили его поддержку и разработку. К счастью, на замену проекта dkim-milter пришел OpenDKIM, с помощью которого добавить DKIM-подпись в письма так же просто.

Хочу обратить ваше внимание на важную, на мой взгляд, проблему, которой пренебрегают даже самые крупные и инновационные компании мира. Проблема заключается в отсутствии у большинства доменов SPF-записи, которая защищает домен от его несанкционированного использования в электронной почте.
SPF (Sender Policy Framework) представляет из себя текстовую запись в TXT-записи DNS домена. Запись содержит информацию о списке серверов, которые имеют право отправлять письма от имени этого домена и механизм обработки писем, отправленных от других серверов.
Например, SPF-запись «example.com. TXT «v=spf1 +a +mx -all»» говорит о том, что отправлять письма от имени домена «example.com» могут сервера, указанные в A и MX-записях этого домена, а письма, отправленные от других серверов должны быть удалены (Fail).

Что такое компания, в которой работает каждый из нас? Это прежде всего люди, которые собрались, чтобы создавать, программировать, внедрять, продвигать. Та команда, которую выбрали вы, приходя на работу, и та команда, которая выбрала вас. Это технологии, которые мы используем и которые мы разрабатываем для мира. Для кого-то  — это стартап, для кого-то — молодая перспективная динамичная компания, для кого-то — гигантская корпорация. Для нас  —  это компания ЛАНИТ, которой 16 октября исполнилось 28 лет. И знаете, мы не можем сказать, много это или мало. С одной стороны, 28 лет — это опыт, с другой — некоторые из наших технологий только появились.


«Восемьдесят три процента всех дней в году начинаются одинаково: звенит будильник». И наши отделы с невероятными названиями начинают работу. Это фото реального стенда с ключами в ЛАНИТ.

В академ-городке Лувэн-ла-Нёв (Louvain-la-Neuve) недалеко от Брюсселя около недели назад прошла 3-х дневная конференция Odoo Experience 2017, которая собрала разработчиков и пользователей Odoo со всего мира.

Я там был, пиво пил, и про Odoo говорил. А этот пост пишу для тех, кто про Odoo ничего не слышал, или до сих пор не пробовал эту прекрасную платформу.

Odoo — это самая популярная в мире открытая платформа для бизнес-приложений, которая развивается с 2005 года (TinyERP -> OpenERP -> Odoo).

Среди пользователей Odoo такие компании, как Toyota, Hyundai, Danone, и другие.

Бизнес-приложения для Odoo доступны как на Odoo маркете, так и в бесчисленных репозиториях на Github.

Всего на Odoo маркете зарегистрировано более 10,000 бизнес-приложений, что делает Odoo маркет самым большим магазином приложений для предприятий.

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

Развитием Odoo занимается бельгийская компания Odoo SA, включенная в список самых быстрорастущих компаний Европы.

Платформа Odoo регулярно получает самые разные награды от авторитетных изданий отрасли бизнес-автоматизации, начиная от The best open source application до
Great User Experience Award и The Rising Star for the ERP software.

Недавно довелось прочитать статью под названием «Мы уволили самого талантливого сотрудника. Это лучшее решение, которое мы когда-либо делали». [Очень популярная статья, которая получила массу положительных оценок на Medium — прим. пер.]

Давайте присядем, вы и я. Нужно поговорить. Если вы не читали статью по ссылке, то уделите 10–15 минут и прочитайте, впитайте её целиком.

Готовы? Отлично. Теперь разберём этот текст, потому что он значит гораздо больше, чем там написано. Если вы прочитали статью, то понимаете, что автор описывает проблемного сотрудника под вымышленным именем «Рик». Рик — это местный гений с огромным количеством знаний в предметной области, он входит в состав ключевых разработчиков продукта.

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

Недавно вышла статья, которую вы наверняка читали, про то, что vim — хорош, а IDE — так себе, скорость набора текста не та.

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

Далее автор предлагает для перемещения по словам вместо ctrl-стрелочка использовать последовательность Esc, e и потом возвращаться в режим редактирования i. Всё это потому, что неудобно удерживать ctrl.

Я знаю, что статьи, рассматривающие vim в невыгодном свете, активно минусуют, но я должен выразить свою позицию.