Имеющиеся реализации расчетных движков на обратной польской нотации, которые можно найти в интернете, всем хороши, только вот не поддерживают функции, такие как round(), max(arg1; arg2, …) или if(условие; истина; ложь), что делает такие движки бесполезными с практической точки зрения. В статье представлена реализация формульного движка на обратной польской нотации, поддерживающего Excel-подобные формулы, который написан на чистом JavaScript в объектно-ориентированном стиле.

Привет, Хабр! Я управляю командами разработки уже 10 лет.

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

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

Поэтому выключаю тумблер «не будь выскочкой» и делюсь «секретами».



Тут не будет стандартных «делегируй», «налаживай процесс», «стой в правильной позе на стендапе» — об этом написано уже достаточно. Будет о другом.

10 июня компания Digital Security провела онлайн-встречу по информационной безопасности Digital Security ON AIR. Записи докладов можно посмотреть на Youtube-канале.

По материалам докладов мы выпустим цикл статей, и первая из них — об уязвимостях PHP-фреймворков уже ждет под катом.

Мы, PHP-разработчики, горды тем, что пишем на ООП-языке (можно легко здесь заменить PHP на C#, Java или другой ООП-язык). Каждая вакансия содержит требования про знание ООП. В каждом собеседовании спрашивают что-нибудь про SOLID или трех "китов" ООП. Но когда дело доходит до дела — мы получаем просто классы, наполненные процедурами. ООП проявляется редко, обычно в коде библиотек.

Обычное веб-приложение — это классы ORM-сущностей, которые содержат данные из строки в базе данных и контроллеры(или сервисы — неважно), содержащие процедуры работы с этими данными. Объектно-ориентированное программирование — оно про объекты, которые владеют собственными данными, а не предоставляют их для обработки другому коду. Отличная иллюстрация этого — вопрос, который был задан в одном чате: "Как я могу улучшить этот код?"

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

Все стало меняться в середине 2000-х годов, когда вебкамеры стали основным компьютерным оборудованием, а на рынок вышел Skype и похожие сервисы. Стоимость и сложность видео-конференций быстро снижались, поскольку все, у кого была вебкамера, быстрый интернет и недорогое программное обеспечение, могли общаться с коллегами, друзьями, членами семьи и даже незнакомцами прямо со своего домашнего или рабочего компьютера. Сейчас же при надежном мобильном интернете или WiFi-соединении и правильном программном обеспечение, видео-конференция может помещаться у вас на ладошке с помощью видео камеры вашего смартфона. Но большая часть этого программного обеспечения является коммерческой.
К счастью, существует несколько отличных альтернатив видео-конференций с открытым кодом, которые повторяют функции Skype, Zoom, Google Hangouts и похожих приложений.

10 июля 2020 года австрийская компания Proxmox Server Solutions GmbH представила публичную бета-версию нового решения по резервному копированию.

Мы уже рассказывали, как использовать штатные методы бэкапа в Proxmox VE и выполнять инкрементальный бэкап с помощью стороннего решения — Veeam® Backup & Replication™. Теперь же, с появлением Proxmox Backup Server (PBS) процесс резервного копирования должен стать удобнее и проще.

Введение

В Веб-Админке Zimbra отсутствуют инструменты для генерации подписи к письмам. Перелопатив кучу мануалов — понял, что ни один из Них меня не устраивает.

Задача кажется тривиальной, но решения в лоб — найти сразу не удалось. Надеюсь, эта статья поможет кому-то сэкономить кучу времени и сил.

С моей же стороны это вклад в сообщество, за ранее использованные наработки.

Привет, меня зовут Михаил Юдин, я Android-инженер в Авито. Хочу рассказать, в чём польза перформанса и как начать внедрять его в продукте. Осенью 2018 года у нас появилась команда перформанса — есть шаги и инструменты, которые нам помогли, поэтому пора делиться опытом.

Что такое Архитектура? Чем Архитектура отличается от Дизайна? Где граница между Архитектурой и Реализацией? Можно ли увидеть Архитектуру? Можно ли тестировать Архитектуру? Чем отличаются Инженерный и Эволюционный подходы к Архитектуре? Что такое Хорошая Архитектура? В чем состоит работа Архитектора? Чем она отличается от работы Разработчика? Какие инструменты доступны Архитектору? Можно ли менять Архитектуру отдельно от Реализации? Есть ли у Архитектуры ДНК?

CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:

• Собирается ли он?
• Проходят ли автотесты?

Тем лучше! CI позволяет делать такие проверки автоматически. Он используется в продвинутых командах разработки, которые пишут не только код, но и автотесты. Его спрашивают на собеседованиях — хотя бы понимание того, что это такое. Да, даже у тестировщиков.

Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту. Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.

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

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

Итак, сайты для обучения программированию онлайн, ТОП 100:

Привет, Хабр! Наверное, в эпиграф можно было бы вынести что-то вроде «чем глубже омут, тем толще черти».

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

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



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

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

Регулярно сталкиваюсь с ситуацией, когда многие разработчики искренне полагают, что индекс в PostgreSQL — это такой швейцарский нож, который универсально помогает с любой проблемой производительности запроса. Достаточно добавить какой-нибудь новый индекс на таблицу или включить поле куда-нибудь в уже существующий, а дальше (магия-магия!) все запросы будут эффективно таким индексом пользоваться.

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

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

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

• неиспользуемые индексы
• префиксные «клоны»
• timestamp «в середине»
• индексируемый boolean
• массивы в индексе
• NULL-мусор

Про принцип единственной ответственности (The Single Responsibility Principle, SRP) уже было написано множество статей. В большинстве из них даётся лишь поверхностное его описание мало чем отличающееся от информации в википедии. А те немногие статьи что затрагивают ключевые особенности SRP делают это вскользь, не акцентируя на них внимания и не развивая тему дальше.

Эта статья — попытка дать более глубокое объяснение принципу единственной ответственности, а также показать как его всё таки можно применять на практике. Кому интересно — добро пожаловать под кат.

Для остановки нет причин — 
Иду, скользя.
И в мире нет таких вершин,
Что взять нельзя.
В. Высоцкий

Если бы эта статья вышла не на Хабре, а в образовательном журнале, я бы начал её так: «Вспомните сайты, которые вам нравятся, на которых удобная навигация и приятный интерфейс. А знаете ли вы, что это только верхушка айсберга…». Но на Хабре это знают, пожалуй все, поэтому никакой лирики. Бэкенд любого веб-проекта — это сложная система, которая позволяет приложению быстро работать, качественно искать, шустро отдавать информацию пользователю, надёжно и безопасно хранить данные и при необходимости работать с другими внешними системами. Это как швейцарские часы: покупают их за стиль и шильдик, но ценители знают, что под сдержанным циферблатом кроется волшебный мир часового механизма. И бэкенд-разработчики — это маги механизмов, организмов, кишочек, внутренностей или как вы ещё это называете у веб-приложений. Эх, без лирики не удалось! 

Короче, сегодня разбираем очередную профессию в серии «Профессия…». Итак, а что, если пойти в бэкенд-разработчики? 

Бэкенд это всегда немного боль

Вопрос производительности PHP-кода для Badoo один из самых важных. От качества PHP-бэкенда напрямую зависят количество ресурсов, которые мы тратим на разработку и эксплуатацию, скорость работы сервиса и впечатление, которое он производит на пользователей.

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



Читайте под катом расшифровку дискуссии, в которой мне повезло быть модератором: как устроена инфраструктура трёх компаний, как мы измеряем производительность и на какие метрики ориентируемся, какие инструменты используем, как делаем выбор между железом и оптимизацией.

А 15 февраля приходите на следующий Badoo PHP Meetup: обсудим легаси.

Вступление

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



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

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

С чего все началось и чем закончилось

Итак, все началось давным давно и довольно банально, как и у большинства моих соотечественников. А именно: 10 лет сидячий жизни в школе = проблемы с осанкой, + 7 лет сидячей жизни в университете = проблемы с осанкой (уже видимо начались непосредственно проблемы с позвоночником) + 10 лет сидячей работы в IT = проблемы с осанкой (уже совершенно точно серьезные проблемы с позвоночником). Я периодически занимался какими-то физическими упражнениями типа игры в футбол, катания на сноуборде или нерегулярных походов на тхэквандо, но, насколько мне кажется теперь, это скорее негативно, чем позитивно отражалось на состоянии моей спины.

Мы в компании КОРУС Консалтинг СНГ уже больше десяти лет занимаемся организацией разработки веб-сервисов для наших заказчиков. У нас за плечами уже несколько десятков серьёзных проектов в банковской сфере, некоторые из них получили международное признание.

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

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