Привет! Меня зовут Настя, я аналитик мобильного приложения Альфа-Бизнес. Иногда меня спрашивают о том, чем я занимаюсь на работе. Друзья, родные и, как это ни странно, разработчики. Каждый раз я отвечают по-разному, пытаясь привести наиболее близкие собеседнику примеры.

«Системный аналитик переводит требования пользователей с человеческого языка на разработческий…» — звучит довольно понятно для человека, не связанного с ИТ. Но если ты непосредственно участвуешь в разработке, вряд ли такого определения будет достаточно. Ради небольшого эксперимента я задала своей команде вопрос: «Чем занимается системный аналитик?». Читаем под катом, что из этого получилось.

Выбор места для нового филиала — ответственное решение. Ошибка может стоить дорого, особенно в капиталоемких отраслях. Чаще всего такие решения принимаются менеджментом экспертно: на основе знания города, отрасли, предыдущего опыта.

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

Население города с точностью до дома

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

Работа с распределенной системой контроля версий Git на примере GitHub
Год начала данной публикации: 2019
Год окончания данной публикации: не указан





Теоретическая часть
Практическая часть
Настройка программы Git
Инициализация локального репозитория
Работа с удаленным репозиторием
Чтобы некоторые ваши файлы не попадали в репозиторий
Модели ветвления в Git
Выводы
.gitignore. Отправка только тех файлов в репозиторий, которые необходимы



Предупреждение по использованию:

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

Знакомьтесь с философией мониторинга, родившейся за несколько десятилетий моих дежурств в разных командах по мониторингу. На нее во многом повлияла настоящая библия от Роба Еващука My Philosophy on Alerting (Моя философия уведомлений), включенная в книгу по Google SRE, и книга Джона Олспо Considerations for Alert Design (Замечания по настройке оповещений).

Келли Данн, Ариджит Мукхерьи и Максим Петаццони — спасибо за помощь в редактировании поста.

Что такое CASE?

Я решил придумать красивую аббревиатуру, как у метода USE Брендана Грегга или метода RED Тома Уилки. Я зову это метод CASE. Он описывает четыре момента, на которые нужно обратить внимание при работе с автоматическим мониторингом:

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

Да, на КДПВ — супруги Мария Склодовская-Кюри и Пьер Кюри.

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

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

Итого, как в таких условиях нарисовать вот такую картинку за 180 строчек кода?

В последние несколько лет мои переживания по поводу российского рынка ИТ только усиливались. Все началось с кризиса рубля 2014 года (а может, и раньше), и с тех пор меня не покидает ощущение, что многие российские компании, особенно провинциальные, завязали себе глаза, заткнули ватой уши и все еще пытаются сделать вид, что ничего не происходит. Я много общался с разными компаниями, с HR, с разработчиками, и составил список неутешительных тезисов о том, что представляет собой как программистский рынок, так и культура разработки в целом, ведь это вещи взаимосвязанные. По моим субъективным оценкам, эти тезисы справедливы для ~60% российских компаний, хотя, казалось бы, те другие 40% компаний, которые мы знаем и любим, должны были заставить задуматься. Но я очень подозреваю, что это эти 60% просто надеются на русский “авось”, и подвергаются так называемой willful blindness, а иногда и намеренно мутят воду. Итак, по-честному, что же происходит?

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

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

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

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

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

void do_something(MyObj *input[], int count)
{
    MyObj **copy = new MyObj*[count];
    for (int i = 0; i < count; ++i)
        *copy[i] = *input[i];
    ...
}

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

Лет десять назад на одном форуме была загадана детская, вроде, загадка:

Для чего еду обеда
Людоедоедоеда
Пригласила на обед
Людоедоедовед?

Я хочу показать, что эта загадка имеет самое прямое отношение к C/C++, поскольку тема указателей легко может быть разобрана по аналогии.

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

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

Умение писать код, который легко отлаживать, начинается с понимания, что вы ничего не помните о ранее написанном.

Предисловие

Какой Shell использовать

Bash единственный язык shell скриптов, который разрешается использовать для исполняемых файлов.

Скрипты должны начинаться с #!/bin/bash с минимальным набором флагов. Используйте set для установки shell опций, что бы вызов вашего скрипта как bash <script_name> не нарушил его функциональности.

Ограничение всех shell скриптов до bash, дает нам согласованный shell язык, который установлен на всех наших машинах.

Единственное исключение составляет если вы ограничены условиями того под что вы программируете. Одним из примеров могут стать пакеты Solaris SVR4, для которых требуется использование обычного Bourne shell для любых скриптов.

Когда использовать Shell

Shell следует использовать только для небольших утилит или простых скрптов-оберток.

Хотя shell-скриптинг не является языком разработки, он используется для написания различных утилит во всем Google. Это руководство по стилю является скорее признанием его использования, а не предложением использовать его в широком применении.

Не влезай. Убьет! (с)

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

Электрический ток

Пути электрического тока неисповедимы. (с) мысли из интернета

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

Здравствуйте, в эфире Радио SQL!

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

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

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

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

Люди часто спрашивают – можно ли попасть на экскурсию по стройке Лахта Центра? Сегодня наступил тот приятный день, когда я, наконец, могу ответить: «Да»!


Фото Виктора Сухорукова

Желающих жду под катом.

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



Известно, что электромеханический принцип воспроизведения звука далеко не безупречен, что связано с появлением паразитных призвуков, резонансов, искажений. При этом психоакустические исследования таких ученых как Флетчер, Линкдайер, Алдошина демонстрируют, что среднестатистический человеческий слух восприимчив к, казалось бы, незначительным изменениям громкости на (0,2 – 0,3 дБ), тембральной окраски, способен определять короткие задержки между сигналами (12 -15 мкс). По этой причине некоторое количество энтузиастов считает, что будущее звуковых излучателей, по крайней мере, ВЧ-драйверов за ионофонами.

Привет Хабр, сегодня я расскажу о том, как я проходил тестовое задание на летнюю стажировку в Яндекс. Эта публикация будет полезна начинающим разработчикам, любителям олимпиадного программирования, тем кто неравнодушен к С++ и Java, или просто хочет прочесть интересную статью после трудного рабочего дня.

Чего ожидать от этой статьи?

• Introduction, о том что такое стажировки в Яндкесе, как и когда на них подать
• Мотивация к написанию данной статьи
• Примеры задач, моё решение и краткий разбор (Можно смело пропустить первые два пункта, и начинать именно отсюда)

Introduction

Для тех кто мало знаком с системой отбора на стажировку в Яндексе расскажу вкратце. На сайте яндекса, за несколько месяцев до лета объявляется оплачиваемая вакансия для начинающих разработчиков, в том отделе, в котором вы бы хотели работать (i.e. Яндекс.Диск, Яндекс.Алиса). По ссылке, нужно заполнить форму, о том где Вы учитесь, чем занимаетесь, какой был опыт работы, о чем писали дипломную работы итп. После заполнения формы Вам на почту присылают тестовое задание, на выполнение которого у Вас есть 6 часов, в любой день в течении недели с момента, когда Вы получили это письмо.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Big Ball of Mud" авторов Brian Foote и Joseph Yoder.

От переводчика: Статья Big Ball of Mud написана Брайаном Футе и Джозефом Йодером летом 1999 года. Она рассказывает о наиболее распространённых антипаттернах разработки ПО, причине их возникновения и развития. Несмотря на то, что с момента публикации прошло больше 18 лет, описанные проблемы никуда не пропали, так что большая часть написанного актуальна и по сей день. Это первая часть статьи из трёх, остальные я надеюсь выложить в ближайшее время.

Введение

В последние годы сразу несколько авторов [Garlan и Shaw, 1993] [Shaw, 1996] [Buschmann и другие, 1996] [Meszaros, 1997] представили паттерны, которые характеризуют архитектуру ПО высокого уровня, например, PIPELINE (конвейер) и LAYERED ARCHITECTURE (многоуровневая архитектура).

В идеальном мире все системы были бы образцом одного или более подобных шаблонов высокого уровня. Тем не менее, в реальной жизни все не так. Архитектура, которая на данный момент является доминирующий, до сегодняшнего дня ещё не обсуждалась. Речь идет о BIG BALL OF MUD или БОЛЬШОМ КОМКЕ ГРЯЗИ.

Я написал программу для очистки отсканированных конспектов с одновременным уменьшением размера файла.

Исходное изображение и результат:


Слева: исходный скан на 300 DPI, 7,2 МБ PNG / 790 КБ JPG. Справа: результат с тем же разрешением, 121 КБ PNG ^[1]

Примечание: описанный здесь процесс более-менее совпадает с работой приложения Office Lens. Есть другие аналогичные программы. Я не утверждаю, что придумал нечто радикальное новое — это просто моя реализация полезного инструмента.

Если торопитесь, просто посмотрите репозиторий GitHub или перейдите в раздел результатов, где можно поиграться с интерактивными 3D-диаграммами цветовых кластеров.