Я был абсолютно двинутый на компьютерах и геймерствовал безбожно. В юности хотел пойти писать игрушки и даже некоторое время писал. Рос, рос, рос. Был в разное время разработчиком, тимлидом, проект-менеджером. Выяснилось, что в проекте надо не только кодить, но и предлагать какие-то решения сходу, обосновывать их, договариваться, быстро переключаться между разнородными задачами. Лично для меня это серьезная нагрузка на мозг. Перейти из режима «кодить» и «говорить ртом» — отнимает много сил.
Конструктор java.lang.Class является одной из самых охраняемых сущностей в языке Java. В спецификации чётко сказано, что объекты типа Class может создавать только сама JVM и что нам тут делать нечего, но так ли это на самом деле?
Предлагаю погрузиться в глубины Reflection API (и не только) и выяснить, как там всё устроено и насколько трудно будет обойти имеющиеся ограничения.
Вообще, я во многих вопросах перфекционист. Если есть — нужно, чтобы было безупречно (иногда это сказывается отрицательно, но сейчас не об этом). Свою аудиоколлекцию я тоже привык держать в чистоте. Но со временем, при пополнении стало накапливаться много мелких неприятностей. Вот некоторые из них:
Разные шаблоны для имен файлов: 4 — Звезда | 04 — Звезда | 04. Звезда
Разные имена исполнителей в тегах: Чиж & Co | Чиж и Ко. | Mylene Farmer | Mylène Farmer
Не указаны исполнители альбома (что приводит к полному бардаку в альбомах-компиляциях)
Не совсем корректная информация об альбомах, состоящих из нескольких дисков
Путаница в годах изданий и переизданий (ремастеринг, и т.д.)
Ну и прочие мелочи.
Часто у пользователей коллекции составляют несколько тысяч, а иногда — несколько десятков тысяч записей. Так что, перелопачивать все вручную — долго и неэффективно.
Данное руководство предназначено для того, чтобы с минимальными затратами привести аудиоколлекцию к максимально упорядоченному виду. В отличие от общедоступной информации, которую можно найти в Интернет, здесь также присутствует мой личный опыт (как положительный, так и отрицательный). В итоге получаем полностью пересортированную коллекцию. Все нижесказанное можно применять для любых коллекций, однако оптимальный вариант — если коллекция по большей части состоит из полных официальных альбомов, с минимальным содержанием разрозненных треков.
Я прислушался ко многим из Вас и внес несколько существенных изменений. Проект активно развивается и завоевывает свою аудиторию, и имеет большие планы на масштабирование.
Для справки: Playble — это мультимедийная поисковая система в реальном времени, которая ищет торренты, фильмы онлайн, и музыку по крупнейшим русскоязычным сайтам.
Создатели проекта The Noun Project поставили целью собрать пиктограммы для всех объектов в мире. Коллекцию по мере сил пополняют десятки дизайнеров из разных стран. Все иконки публикуются в формате SVG, под лицензией Creative Commons Attribution 3.0 (CC BY) или Public Domain, разбиты на тематические категории, есть поиск на русском языке.
Многие уже в курсе, что 1 июля окончательно вступили в силу положения закона ФЗ-152 «О персональных данных». Федеральный закон, регулирующий деятельность по обработке (использованию) персональных данных, претерпел значительные изменения, которые могут сильно подпортить бизнес большинству компаний.
Согласно новым требованиям, компании, в которых на компьютерах обрабатывается или используется персональная информация физического лица, обязаны поддерживать высокую защищенность этих данных, используя сертифицированные средства защиты.
В связи с тем, что на данный момент менее 5% компаний готовы соблюдать эти требования, на рынке появилось множество системных интеграторов и специалистов в области информационной безопасности, готовых помочь компании продолжить работать в штатном режиме за N-ую сумму (от 10 000 рублей до unlim рублей).
На Хабре мелькали статьи, в которых авторы призывали системных администраторов и IT-менеджеров готовиться к «судному дню».
Ну что же, «судный день» настал, и я хочу поделиться собранной информацией по этой теме. Надеюсь, эта информация поможет многим сэкономить десятки, а то и сотни тысяч рублей.
Давно подметил, что веб-проекты отличаются разными классами «свежести»…
Первой свежести
Программисты редко уходят из таких проектов, т.к. удовольствие от возможности работать с правильным кодом и разумной архитектурой нередко подавляет периодические позывы о повышении зарплаты и карьерном росте. Человек может реально трудиться и три, и пять лет, особенно если ему дают возможность стать сопричастным продукту и добавить в него часть своего мозга и сердца.
Для менеджера управлять развитием такого продукта, путем итераций + ТЗ, или путем работы в доверительном Scrum/Agile-режиме — приятно. Зазубрины некритичных рисков и фрагментальных сдвигов сроков сглаживаются общим ощущением надежности и жизнеспособности продукта. Менеджер горит идеями, богатеет фичами, а после регулярной реализации самых приоритетных задач получает дозу морального удовлетворения и оптимизма… и желает дальше работать в этой компании :-)
Техническая поддержка занимается исправлением незначительных ошибок, собирая в основном в приоритезированные букеты пожелания клиентов.
Короче ощущается что-то вроде благоухания и благоговения, причем это отмечают все — и топы, и менеджеры, и разработчики, и саппорт.
К сожалению, такие проекты/продукты встречаются… нечасто. Но — встречаются.
Второй свежести
Программисты всеми правдами и неправдами пытаются протиснуться и перескочить на задачи, связанные с «правильными» модулями/компонентами продукта. Там действительно порядочек, чисто и есть желание добавлять что-то новое, проявить творчество.
Большой брат следит за тобой. И за плохими парнями тоже.
В середине марта на мой телефон пришло смс с незнакомого номера, но вместо уже наскучившего «Мама, у меня проблемы, скинь мне денег на номер» пришел новый спам «Принято новое ммс от пользователя. Для просмотра ммс в телефоне перейдите по ссылке» и дан адрес сайта.
Вместо обещанного пронаммс с сайта стал скачиваться jar-файл.
На хабре уже были статьи по анализу работы таких приложений. Попробуем другой путь, ведь этот спам — хороший повод проверить работу правоохранительных органов в сфере высоких технологий.
Спойлер: плохих парней не нашли, но телефонные номера взяты на контроль.
Обзор свободно доступных и бесплатных IP АТС: Asterisk, FreeSWITCH, SipXecs, Yate. Приводятся преимущества и недостатки, сравнительный анализ функциональности и сфер применения. Делается вывод о том, что все продукты можно сочетать друг с другом.
Некоторое время назад ко мне обратился товарищ из «Открытых Систем» и попросил сделать обзор открытых IP АТС. Так как он обратился не только ко мне, а еще и к другим экспертам IP телефонии, то в результате в журнал попала компиляция, в которой мало осталось от моего оригинального обзора. Публикую его целиком на Хабре.
Вначале будет теоретическая вставка, для тех, кто не совсем в теме. Если будет скучно — просто пропустите ее! Приятного чтения! А чтобы лучше читалось, главы сопровождаются музыкальными подарками (настоятельно рекомендую наушники :-)
Поехали!
Теория
PBX (Private Branch Exhange) — английский термин, обозначающий офисную телефонную станцию, которая обеспечивает установление, поддержание и разрыв соединений между аппаратами, то есть коммутацию. PBX позволяет разделять ограниченные ресурсы (городские линии и номера) между неограниченным числом внутренних пользователей, при помощи таких телефонных функций, как внутренний номерной план, перевод звонков, постановка на удержание, и других.
Именно поэтому PBX система необходима любой организации — она позволяет эффективно организовать телефонную связь на предприятии (ну, пока еще нужна ;-)
Продолжение «опытных мелочей». Предыдущие части: раз, два, три.
Сегодня я расскажу о принципах делания бэкапа, которые выстроились в результате проб и ошибок, и не раз спасали ситуацию в самый, казалось бы, неожиданный момент.
В предыдущих статьях (первая, вторая) мы бегло и в шутливой форме прошлись по примерам противодействия, которое оказывают нам сотрудники заказчика на различных этапах проекта. Сегодня предметом рассмотрения будет сдача работ, и мы подойдем к этому этапу во всеоружии, чтобы ни один тролль не прорвался. Получилось много букв, но, надеюсь оно того стоит.
Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.
Процесс приемо-сдаточных испытаний должен быть строго формализован. Всем понятно, что в конце этого процесса должен появиться протокол и акт, на основании которого выпускается приказ о переводе системы в опытную или промышленную эксплуатацию. Акт также является формальным поводом для выставления счета на оплату очередного этапа проекта.
В этой статье я без лишних шуток (какие уж тут шутки!) и максимально последовательно (ну, для блога, конечно) опишу процесс сдачи проектных работ. Разумеется, многие вещи опытным коллегам покажутся очевидными. Пусть. Зато менее опытные коллеги или желающие примерить ответственную роль сдающего на себя найдут эту публикацию полезной и познавательной.
Видя, когда новички верстая страницу за страницей, допускают кучу ошибок, делая отступы маргин и до конца не понимая, как этот самый маргин на самом деле работает, я решил написать данную статью.
Начинающим верстальщикам она точно будет полезна, а вот профессионалам — сомневаюсь, так как человек занимающийся не первый год версткой уже обязан «вызубрить» наизусть все особенности данного свойства.
В этой части статьи я напишу о вертикальном маргине. О горизонтальном поговорим в следующей части.
Как у разработчика, очевидно, что ваш основной рабочий инструмент, который позволит вам быстро идею превратить в код: текстовый редактор. Время идёт, и теперь нам доступно множество онлайновых текстовых редакторов, которые могут помочь вам создавать свой код с любого компьютера, имеющего доступ в интернет. В этой статье рассмотрим более 10 таких редакторов.
Amy Editor
Созданый в 2007 Петром Кронторадом (Petr Krontorad), Amy Editor продвинутый редактор с интерфейсом в стиле Mac. Amy Editor имеет в наличие кучу полезных опций, такие как нумерация строк, подсветка синтаксиса, сниппеты для более чем 20 языков, совместное использование и прочее.
» http://www.amyeditor.com
Давайте представим, что вас попросили возглавить одно из направлений в вашей компании. Вы, конечно же, знаете всех людей в команде, неоднократно пересекались в коридорах и пили пиво на корпоративах. Прошлый руководитель был неплохим человеком, но у него изменились планы и он уволился.
И вот, вы, принимая пост, знакомитесь с командой: вроде бы есть потенциально сильные разработчики с опытом, есть несколько подающих надежды юниоров. Но что-то сразу бросается в глаза. И чем дольше вы вглядываетесь в эти занятые работой умные лица, тем более понимаете, что перед вами не команда, а «группа разработчиков». А то, что они пишут… Вы и не думали, что программисты могут так писать код. Вы смотрите на пластилиновую архитектуру, на классы в 6000 строк кода, на методы, занимающие десять страниц машинописного текста, на кейсы, ветвящиеся как головы Лернейской гидры. И у вас появляется невольный вопрос: а можно ли что-то с такой командой сделать вообще?
Ни для кого не секрет, что в настоящее время многие стремятся к минимализму в дизайне чего бы то ни было. Действительно, когда нет ничего лишнего, то повышается и восприимчивость информации. Но это все лирика. Сказано было это еще до меня и много. Предлагаю вашему вниманию подборку сайтов, посещение которых может направить ваши мысли по поводу разрабатываемого дизайна в нужное русло.
Продолжение «опытных мелочей». Предыдущие части: 
