Предисловие

Хочется в начале сказать о том, кому статья точно не пригодится. Таковых, как минимум, две категории. Первая — это те, кто вообще не сталкивался с компаниями, или имеет свой стартап и работает сугубо на себя самого. Вторая категория — это те, кто даже после прочтения вот этой моей статьи, думает, что его место работы самое прекрасное, и в таких условиях он хочет провести всю свою карьеру и ничего более не возжелать.
Для тех же, кто работает в условиях где уже ощутил на себе понятия — сроки, overtime, ASAP, работа на выходных, посвящается…

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



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

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

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

1) я написал заявление на увольнение по собственному желанию
2) я написал заявление на отпуск без сохранения зп
3) поверил, что головная контора выплатит долг

Это всё стало понятно после суда. По договору был срок полгода, когда должны выплатить остатки зп. Когда стало понятно, что я ничего не получу, пошли в суд. Суд посчитал недоказанным, что мы фактически работали во время фиктивного отпуска.

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

Задача

Настроить использование RBAC в Yii2.

Условия

Список возможных ролей:

• guest — не авторизованный юзер;
• BRAND — авторизованный юзер, наследует разрешения роли guest и имеет свои уникальные разрешения;
• TALENT — авторизованный юзер, наследует разрешения роли guest и имеет свои уникальные разрешения;
• admin — авторизованный юзер, наследует разрешения ролей guest, BRAND и TALENT и имеет свои уникальные разрешения.
• Роль определяется полем group в модели UserExt;
• Роли имеют вложенную структуру — одна роль может наследовать разрешения другой;
• Используется yii\rbac\PhpManager;
• Не использовать назначение роли юзеру по его ID — вместо этого использовать несколько предустановленных ролей (defaultRoles);
• Генерирование конфига «роль-разрешения» будет делать консольная команда yii;
• Будут использованы расширенные правила (Rules) для разрешений.

Предварительная настройка

app/config/console.php

'components' => [
    // ...
    'authManager' => [
        'class' => 'yii\rbac\PhpManager',
    ],
    // ...
],

app/config/web.php

'components' => [
    // ...
    'authManager' => [
        'class' => 'yii\rbac\PhpManager',
        'defaultRoles' => ['admin', 'BRAND', 'TALENT'], // Здесь нет роли "guest", т.к. эта роль виртуальная и не присутствует в модели UserExt
    ],
    // ...
],

Создать директорию @app/rbac — именно в ней будут находиться разрешения и правила.

Доброго времени суток, уважаемые хабравчане. Сегодня я хочу поделиться с вами одним небольшим событием — ровно год назад, 15 августа 2013 года я опубликовал свой первый дайджест для веб-разработчиков. С тех пор было опубликовано 25 выпусков и мои подборки обрели некоторую «популярность», а мне приятно ощущать себя «полезным» для хабраобщества.

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

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

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



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

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

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

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

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

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



Я вижу здесь сразу несколько проблем: ручные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам; ручные тестировщики не знают, что именно покрывается автотестами; автоматизаторы тратят время на разбор отчётов. Как ни странно, но все три проблемы вытекают из одной: результаты выполнения тестов понятны только автоматизаторам — тем, кто эти тесты писал. Именно это я и называю непрозрачностью.

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

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

Совсем недавно я игрался с некоторыми функциональными языками и их концепцией, и заметил, что некоторые идеи функционального программирования могут быть применимы и к объектному коду, который я писал ранее. Одной из таких идей, о которых стоит поговорить — это Монады. Это что-то такое, о чем пытается написать туториал каждый кодер на функциональном языке, так как это крутая, но трудно понимаемая штука. Этот пост не будет туториалом по Монадам (для этого есть вот этот замечательный перевод от AveNat) — скорее пост о том, как использовать их с пользой в PHP.

Что такое Монады?

Если пост выше не удалось дочитать до конца (а зря!), то Монаду можно представить неким контейнером состояния, где разные Монады делают разные вещи относительно этого состояния. Но лучше таки прочитать. Также будем считать, что мы уже немного поигрались с библиотекой MonadPHP из GitHub, так как в примерах использоваться будет именно она.

Привет, дорогие читатели хабра. В этой статье поговорим

• Про адреса и хранилища данных с нечеткой схемой
• Про обработку геоданных на java, а именно про Java Topology Suite
• Про стоимость «простоты» для разработчика
• Про pure Java nosql документную бд / движок полнотекстового поиска — Elasticsearch.

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

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

Для мониторинга IT-инфраструктуры мы используем множество инструментов, в том числе:

• Zabbix — о нем написано немало статей здесь на хабре. Нам очень нравятся его возможности низкоуровневого обнаружения, но его возможности визуализации данных оставляют желать лучшего.
• Graphite — система, которая хранит данные и имеет удобный интерфейс для их отображения. Сейчас мы импортируем в нее метрики из Zabbix и храним историю.
• Shinken — система мониторинга, которая основана на Nagios и написана на языке Python. Сейчас мы присматриваемся к ней. Нам нравится то, что в нее очень просто импортировать данные из системы документации сети Netdot (о ней я уже писал ранее), а также она легко интегрируется с Graphite.

Можно долго обсуждать преимущества/недостатки тех или иных систем мониторинга, но я хочу остановиться только на одном вопросе — выявлении аномалий. Когда в вашей системе мониторинга количество метрик измеряется сотнями, отследить аномальное поведение одной или нескольких из них не составляет труда. Но когда количество метрик измеряется десятками или сотнями тысяч, вопрос автоматического выявления аномалий становится актуальным. Ни один администратор или группа администраторов не в состоянии вручную отследить поведение сложной системы, состоящей из сотен устройств.
Инженеры из Etsy в свое время столкнулись с этой проблемой и разработали свой инструмент для обнаружения и корреляции аномалий. Называется он Kale и состоит из двух частей:

• Skyline
• Oculus

Мы уже рассказали вам, что такое Cocaine и как его развернуть «в домашних условиях». Сегодня речь пойдёт о том, как пользоваться его инфраструктурой на уровне программиста. Кстати, 26 апреля в 14:00 в московском офисе Яндекса пройдет встреча, на которой можно будет вживую пообщаться с нами — командой, которая делает Cocaine. Приходите, но не забывайте регистрироваться.



Итак, из сегодняшнего поста вы узнаете:

• как писать приложения;
• как пользоваться приложениями и сервисами нативно, используя предоставленные фреймворки;
• как изменить приложение, чтобы оно отвечало по http, а также как потестировать эти приложения, используя Cocaine http proxy;
• как написать собственный сервис.

Давайте же начнем наше погружение в «кокаиновые» будни программиста.

Глобализация рынка труда по-новому поставила вопросы выбора работников. В погоне за максимально дешевой рабочей силой компании США и Европы обратились к индийским (китайским, российским, украинским) информационным производителям. «Спрос» на индийских специалистов перевернул как внутреннюю структуру рынка труда, так и систему образования.

Изменения, произошедшие в Индии в 2000-е, получили название «Индийской IT революции». «Революция» сопровождалась быстрым ростом количества специалистов, занятых в IT индустрии (составляющих сегодня около четверти от всей массы работников) и умножением суммарного вклада отрасли в национальный ВВП. В итоге, к концу 2000-х образовалась ситуация, при которой огромная часть населения Индии, устроившись на работу в офисе в Chennai или попав в местную «силиконовую долину» Bangalore, в действительности выполняет работу для клиентов из Сан-Франциско или, к примеру, Нью-Йорка.

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

Волею судеб мне довелось разбираться с организацией многозадачности, точнее псевдо-многозадачности, поскольку задачи делят время на одном ядре процессора. Я уже несколько раз встречала на хабре статьи по данной теме, и мне показалось, что данная тема сообществу интересна, поэтому я позволю себе внести свою скромную лепту в освещение данного вопроса.
Сначала я попытаюсь рассказать о типах многозадачности (кооперативной и вытесняющей). Затем перейду к принципам планирования для вытесняющей многозадачности. Рассказ рассчитан скорее на начинающего читателя, который хочет разобраться, как работает многозадачность на уровне ядра ОС. Но поскольку все будет сопровождаться примерами, которые можно скомпилировать, запустить, и с которыми при желании можно поиграться, то, возможно, статья заинтересует и тех, кто уже знаком с теорией, но никогда не пробовал планировщик “на вкус”. Кому лень читать, может сразу перейти к изучению кода, поскольку код примеров будет взят из нашего проекта.
Ну, и многопоточные котики для привлечения внимания.

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

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

В свободное время я написал приложение, специально заточенное для поиска статей. Его возможности:

• добавление статьи одной кнопкой из браузера
• автоматическая категоризация
• русская и английская морфология
• просмотр текста статьи
• операторы поискового запроса

Несколько часов назад сотрудники The OpenSSL Project выпустили бюллетень безопасности, в котором сообщается о критической уязвимости CVE-2014-0160 в популярной криптографической библиотеке OpenSSL.

Уязвимость связана с отсутствием необходимой проверки границ в одной из процедур расширения Heartbeat (RFC6520) для протокола TLS/DTLS. Из-за этой маленькой ошибки одного программиста кто угодно получает прямой доступ к оперативной памяти компьютеров, чьи коммуникации «защищены» уязвимой версией OpenSSL. В том числе, злоумышленник получает доступ к секретным ключам, именам и паролям пользователей и всему контенту, который должен передаваться в зашифрованном виде. При этом не остается никаких следов проникновения в систему.

Наверное, все уже слышали о чудесной библиотеке asyncio?

Если нет, то коротко: эта либа стала стандартом на асинхронное сетевое программирование на Python. tornado и twisted или научатся с ней работать или постепенно уйдут в маргиналы.

asyncio прекрасна, но это просто библиотека для работы с TCP, UDP, UNIX сокетами, PIPES и асинхронным запуском subprocess.

Чтобы всем было здорово нужны сторонние библиотеки, умеющие работать с asyncio. Кое-что уже есть, но мало.

Вот я с коллегами и сделал пару: одну для ZeroMQ и другую для PostgreSQL

Если вы прочно сидите на Python 2 и не интересуетесь Python 3 — не ходите под кат во избежание глупых вопросов и прочих недоразумений.

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

«Почему бы просто не взять и использовать Heroku?», спросите вы.
Прежде всего, я могу запустить Docker и Ansible на любой машине, с любым хостинг провайдером. Во вторых, я предпочитаю гибкость, удобству. Я могу, таким же образом, запускать все что угодно, не только web приложения. Ну и напоследок, потому что я эксперементатор в душе, я получаю удовольствие от понимания того как оно все вместе работает. Фундаментальная основа Heroku это Linux контейнер. Та же технология лежит и в основе Docker'a. На самом деле, одним из девизов Docker'a является «Контейнеризация это новая виртуализация»