Чё, зачем, почему

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

Совсем недавно мы опубликовали статью с описанием проблем одной из самых популярных технологий, используемых в IT, и на наше удивление она вызвала достаточно живой интерес (во всяком случае для технической статьи). Поэтому мы решили на этом не останавливаться, и сегодня мы «идем в гости» к одному из самых популярных продуктов на российском рынке разработки бизнес-приложений — платформе 1С.

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

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

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

Статистика – вещь упрямая. И согласно аналитике за последние пять лет 65% случаев утечки информации в компаниях произошли из-за действий инсайдеров. Более 95% записей скомпрометированы по неосторожности — от незнания правил по обращению с данными или из-за сбоя в системе. Процент утечки персональных данных от общего количества инцидентов все пять лет не опускался ниже 60%.

В лидерах по утечкам — B2C-компании, имеющие большую клиентскую базу: это розничные банки, МФО и операторы связи. От самых громких утечек за последние пару лет пострадало более полумиллиарда учетных записей – напомню некоторые из них, чтобы не быть голословным.

Прим. перев.: То, что сегодня принято называть SRE (Site Reliability Engineering — «обеспечение надежности информационных систем»), включает в себя большой спектр мероприятий по эксплуатации программных продуктов, направленных на достижение ими необходимого уровня надежности. Мониторинг — одно из ключевых мероприятий, а «золотые сигналы» образуют главные метрики, которые должны в нём учитываться. Не найдя на Хабре ни одного материала про них, мы решили перевести небольшую заметку от авторов платформы для управления инцидентами (VictorOps), дающую представление общее представление об этом подходе.



Эффективный site reliability engineering (SRE) опирается на глубокое понимание базовой инфраструктуры сервиса и архитектуры. Повышение прозрачности состояния приложения и инфраструктуры — это только начало проактивной работы над созданием надежных систем. При этом наилучшей отправной точкой для мониторинга состояния систем считаются так называемые «четыре золотых сигнала» (four golden signals) SRE. Наладив эти четыре базовых метода мониторинга, можно переходить к дальнейшему повышению прозрачности системы.

Итак, хабровчане, уже в этот четверг в OTUS стартует курс «Fullstack разработчик JavaScript». И сегодня мы делимся с вами еще одной авторской публикацией в преддверии старта курса.



Автор статьи: Павел Якупов

---

В этой статье мы поговорим о самых простых и распространенных паттернах проектирования в языке Javascript — и постараемся объяснить, какие из них когда нужно применять.
Что такое вообще паттерны проектирования? Паттерны проектирования это термин, который используется для общих, часто используемых решений для общих проблем в создании программ.

Говоря проще, паттерны проектирования — это удачные решения, которые используются достаточно часто. Паттерны проектирования как понятие сформировались еще в то время, когда языка программирования JavaScript не было в помине, в сфере software engineering паттерны проектирования были подробно описаны еще в 1994 году «Большой четверкой». Однако мы в нашей статье обратимся к реализации некоторых несложных паттернов именно на языке программирования JavaScript.

Вашему вниманию предлагается перевод поста Гергелия Ороса, занимающего должность Engineering Manager в Uber. В нем он делится своим взглядом на проектирование крупномасштабных систем, основанном на собственном практическом опыте работы в Uber и Microsoft. В сочетании с комментариями на Hacker News, которые добавляют весомые контр-аргументы и дополняют точку зрения автора, его статья стала одним из самых интересных постов недели. В статье используется термин «дизайн кода» для сравнения с традиционной «архитектурой» — о нем подробнее можно прочитать здесь.

На мою долю выпало достаточно опыта в проектировании и создании крупномасштабных систем. Я принимал участие в переписывании распределенной системы платежей в Uber, проектировании и релизе Skype на Xbox One и выпуске в открытый доступ RIBs — мобильного архитектурного фреймворка, созданного в Uber. Все эти системы имели тщательно продуманный дизайн, прошли через несколько итераций, с ними связано множество совещаний, проведенных у маркерной доски, и других обсуждений. Затем придуманный дизайн сводился к дизайн-документу, который распространялся среди других разработчиков для сбора дополнительной обратной связи, который продолжался до тех пор, пока мы не переходили к разработке.

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

Привет, Хабр. Не так давно я с большим интересом прочла здесь несколько статей со здравыми рекомендациями заботиться о сотрудниках до того, как они «сгорят», перестанут выдавать ожидаемый результат и в конечном итоге приносить пользу компании. И ни одной — с «другой стороны баррикад», то есть от тех, кто действительно выгорел и главное, справился с этим. Я — справилась, получила рекомендации от бывшего работодателя и нашла работу ещё лучше.

Собственно, что делать руководителю и команде, достаточно хорошо написано в «Сгоревшие сотрудники: есть ли выход» (uyga) и «Гори, гори ясно, пока не погасло» (Lisichkina). Краткий спойлер от меня: достаточно быть внимательным руководителем и заботиться о сотрудниках, остальное — разные по степени эффективности инструменты.

Но я убеждена, что ≈80% причин выгорания лежат в личностных особенностях сотрудника. Вывод основан на моём опыте, но думаю, это справедливо и для других выгоревших. Более того, мне кажется, что более ответственные, переживающие за своё дело и внешне перспективные, покладистые работники выгорают чаще, чем остальные.


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

Во первых словах:

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

Сейчас я обосную этот тезис с научной точки зрения.

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

Весной мы добавили в API DaData.ru фичу «Обратное геокодирование», она же «Адрес по координатам». Название намекает: метод принимает геокоординаты и отдает данные об адресе.

Солидный продукт с той же функциональностью предлагает «Яндекс» — он называется «Геокодер». Но сервис «Яндекса» бесплатен только для открытых некоммерческих проектов. Стандартный же тариф — от 120 000 ₽ в год — подходит не всем.

Мы подумали — если сделать бесплатную или недорогую альтернативу «Геокодеру», разработчики наверняка скажут спасибо. И сделали. В статье расскажу, как устроен «Адрес по координатам»: как мы наладили поиск, собрали справочник и упаковали в готовый метод.

Содержание

• Описание метода
• Применение тестировщиками
  
  • Строка данных
  • Файл
• Применение разработчиками
• Резюме

Иногда баги сами нас находят. Вот мы впихали большую строку данных — и система подвисла. Это она из-за 1 млн символов упала? Или ей какой-то конкретный не понравился?

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

Если найти минимальные данные для воспроизведения, то:

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

Как найти минимальные данные для воспроизведения бага? Если есть какие-то подсказки в логах, применяем их. Если подсказок нет, то самый оптимальный метод — метод бисекционного деления (также известный как метод «деления пополам» или «дихотомия»).

Описание метода

Метод применяется для поиска точного места падения:

1. Взять падающую пачку данных.
2. Разбить пополам.
3. Проверить половину 1
   
   
   • Если упало — значит, проблема там. Работаем дальше с ней.
   • Если не упало → проверяем половину 2.
4. Повторяем шаги 1-3 до тех пор, пока не останется одно падающее значение.

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

Вступление

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

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

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

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

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

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

Они помогут вам:

• глубже продумать свой макет
• избежать лишних вопросов
• получить более качественный результат
• остаться друзьями с frontend-разработчиком

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

Я в общих чертах расскажу о перекрестной репликации между PostgreSQL и MySQL, а еще о методах настройки перекрестной репликации между этими двумя серверами базы данных. Обычно базы данных в перекрестной репликации называются однородными, и это удобный метод перехода с одного сервера реляционной СУБД на другой.

Базы данных PostgreSQL и MySQL принято считать реляционными, но с дополнительными расширениями они предлагают возможности NoSQL. Здесь мы обсудим репликацию между PostgreSQL и MySQL, с точки зрения реляционных СУБД.

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

Привет, Хабр. Это статья о том как написать Hello world по последнему слову техники.

В конце мы получим hello world библиотеку которая:

• Использует typescript
• Заботится о codestyle
• Генерирует доку
• Проводит тесты

Этот текст — перевод репозитория viraptor. Вы можете предложить свои вопросы на английском, в оригинальном репозитории, или на русском — в моём форке, а я постараюсь перевести их и передать автору

Обратное собеседование

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

Если вы задавали вопросы, которых нет в этом списке, отправьте пожалуйста пулл-реквест!

Необходимое вступление

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

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

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

Это будет небольшая история про большую лень.

Так сложилось, что задача поиска людей в команду упала на менеджера проекта. А роль менеджера проекта упала на меня. This is a story of my life...

Привет, завтра мы собираем за одним столом руководителей разработки из разных известных компаний — обсудим 6 вечных вопросов: как замерять эффективность разработки, внедрять изменения, нанимать и так далее. Ну а накануне решили поднять седьмой вечный вопрос — что читать, чтобы расти?

Профессиональная литература — сложный вопрос, особенно если говорить о литературе для руководителей в сфере IT. Чтобы понять, на что потратить вечно не хватающее время, мы опросили подписчиков канала «Тимлид Леонид» и собрали подборку из полусотни книг*. А затем добавили отзывы наших тимлидов к самым популярным. Так как список ниже глубоко субъективен и основан на отзывах незнакомых вам людей, оценивать литературу мы будем в «сферических совах».

---

1. «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо» / Дорофеев Максим

TL;DR

Из книги вы узнаете:

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

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

Оценка: 6,50 сферических сов.

---