Пользователь
Эта публикация — логическое продолжение поста «Как настройка переменной окружения TZ позволяет избежать тысяч системных вызовов». Здесь мы рассмотрим характерную ситуацию, когда микрооптимизации (например, удаление системного вызова) очень сильно влияют на производительность.
Пока что не все системные администраторы насладились в полной мере знакомством с криптолокерами, хотя стараются многие. В этой статье я расскажу, что нужно сделать, чтобы облегчить попадание шифровальщика в инфраструктуру и обеспечить максимально разрушительные последствия.
«Code Monkey like Fritos
Code Monkey like Tab and Mountain Dew
Code Monkey very simple man
With big warm fuzzy secret heart:
Code Monkey like you
Code Monkey like you»
Привет, Хабр! Меня зовут Слава Волков, и я фронтенд-разработчик в Badoo. Сегодня я хотел бы немного рассказать про сбор статистики с фронтенда.
Мы знаем, что аналитика позволяет оценить эффективность работы любого веб-сайта, улучшить его работу, а значит, повысить уровень продаж и усовершенствовать взаимодействие пользователей с сайтом. Проще говоря, аналитика – это способ контроля над процессами, происходящими на веб-сайте. В большинстве случаев для обычных сайтов достаточно установить Google Analytics или «Яндекс.Метрику» – их возможностей вполне достаточно.
Но как быть, когда стандартных средств мониторинга недостаточно? Или когда собираемая статистика должна быть интегрирована в вашу собственную систему аналитики для отображения полноценной картины происходящего между разными компонентами? В таком случае, скорее всего, вам придется разработать свою систему. А вот как лучше отправлять статистику с ваших веб-сайтов, какие проблемы могут при этом возникнуть и как их избежать, я расскажу в этой статье. Заинтересовались? Добро пожаловать под кат.
Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.
Как сказано в Википедии:
В программной инженерии шаблон проектирования приложений — это многократно применяемое решение регулярно возникающей проблемы в рамках определённого контекста архитектуры приложения. Шаблон — это не законченное архитектурное решение, которое можно напрямую преобразовать в исходный или машинный код. Это описание подхода к решению проблемы, который можно применять в разных ситуациях.
Будьте осторожныВ статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.
QSystemSemaphore. 
Привет, Хабр!
Недавно мы публиковали свои экспериментальные публичные собеседования. Конечно, это не совсем настоящие собеседования, потому что мы концентрировались на технических темах и почти не затрагивали личные качества человека. К тому же, собеседования проводились «в вакууме», без допущения о компании, проектах и команде, в которую кандидат пытается попасть. В сегодняшнем переводе рассматривается тема рекрутинга на основе личности, характера и доверия.
Есть куча гайдов, помогающих провести собеседование. Они содержат множество полу-осмысленных микро-советов по основам психологии. Или просто набор, возможно, осмысленных вопросов для проверки разных навыков. Я прочитал много таких гайдов, книжку про техники проведения собеседований, и даже прошел специальный тренинг.
У всех этих источников есть общая черта: ни один не сделал из меня более крутого собеседующего, и ничто не улучшило качество рекрутинга (это, конечно, не численная оценка, а мое личное ощущение). Ну, может, не все так плохо. Конечно, я изучил что-то новое и полезное, и стал задумываться о процессе собеседования глубже. Что, в итоге, очень хорошо.
Проблема этих гайдов в том, что они сделаны для обеих сторон. Кандидат и интервьювер читают одни и те же странные статьи и искусственно разговаривают по записанным на бумажку темам, задают одни и те же вопросы, на которые есть готовые ответы. И решение о найме может приниматься на основе количества изученного собеседником материала про собеседования.
Маргарет Гамильтон стоит рядом с написанным ей исходным кодом бортового компьютера «Аполлона»
Лаборатория реактивного движения (Jet Propulsion Laboratory) — научно-исследовательский центр НАСА, ответственный за большинство беспилотных космических кораблей США. Там пишут много кода, и права на ошибку у них намного меньше, чем у обычных программистов.
В JPL пишут на Си, и на их сайте есть документ "JPL Institutional Coding Standard", описывающий жесткие стандарты кодирования внутри организации. Они напоминают правила программирования для встроенных (embedded) систем и систем реального времени, с ограниченными ресурсами. Но многие из правил эти просто принципы хорошего программирования. Ограничение сложности, максимальное упрощение для последующего чтения кода и отладки, отсутствие побочных эффектов. Мы в Хекслете постоянно говорим об этом в вебинарах и, конечно, в самих курсах. Мы считаем очень важным как можно раньше поднимать эти темы, поэтому про функции и побочные эффекты начинаем говорить в самом первом курсе «Основы программирования», который рассчитан на новичков. Это бесплатный курс, кстати, и в нем есть практика на языке JavaScript.
Спасибо хабраюзеру Boletus за важную поправку и дополнение:
В 2006 году Gerard Holzmann с коллективом сформулировал 10 основных правил для JPL в документе «The Power of 10: Rules for Developing Safety-Critical Code». Они вошли в основу нынешнего стандарта, наряду с MISRA C и другими дополнениями. Статья в Википедии.
Вот перевод этого списка.
