Больше половины из поиска (срез за последние 30 дней). Это люди, которые что-то ищут, им нужно какое-то решение, но не развлечение. У развлекательных сайтов другой паттерн и источники трафика.
Вот еще один график, о котором мы говорили. У Хабра очень лояльная аудитория. К октябрю доля тех, кто возвращается, будет в районе 75% (в статистике есть август, многие еще были в отпусках).
Проблема в том, что PostCSS — это новый класс инструментов. В том-то и дело, что это и не просто замена Sass, и не таск раннер.
Но может вам поможет такое сравнение — PostCSS — это как Babel 6 (который с плагинами и может делать всё что угодно, а не только ES6), только для CSS. У PostCSS даже есть cssnext, который как раз «CSS4» делает.
Согласен, с годами на FOSDEM становится всё больше народу и как-то всё перемешано стало.
Посещаю эту конференцию с 2004 года каждый год (мне ехать недалеко) и раньше было как-то более конкретно всё, презентовались действительно сложные вещи и докладчики были все очень компетентные.
Последние годы наблюдаю что конфа сползает из общения увлечённых техникой гиков в площадку для пиара разных проектов.
Много раз уже предлагали делать предварительное голосование на сайте чтобы выявить популярность докладов и правильно распределить аудитории. Но нет, политика взяла и в этом году верх.
В итоге например все презентации по системам виртуализации-докеру-оркестрации проходили в сравнительно небольшой аудитории и примерно такое же количество людей толпилось в коридоре в надежде туда попасть. В то же время я видел полупустой Janson заполненный хорошо если на треть.
Нет, в целом я очень доволен конечно тем что и в этом году там был. Встретился со всеми с кем хотел, всё обсудил.
Для желающих посетить конфу в следующем году советую заранее подготовиться и идти общаться по интересам, это наиболее эффективно.
Не забывайте, что irq affinity можно навешивать не только на сетевухи, но и на storage девайсы
Новые сетевухи умеют `adaptive-rx`/`adaptive-tx`, совсем новые `rx-usecs-high`
NUMA лучше не interleave'ить, а использовать по назначению. Запустите N инстансов приложения. Каждое на своей ноде. Каждой свой CPU и память, а так же сетевуху (NUMA ноду для irq affinity через можно определить от /sys/class/net/eth*/device/numa_node) и свой набор IP'шников. Далее на вышестоящем балансере (я так пологаю IPVS) считать каждую NUMA-ноду за отдельный хост
Для файлсерверов очень опасна/proc/sys/vm/zone_reclaim_mode — важно, чтобы оно было выставленно в ноль
Уже не совсем в тему оптимизации производительности, а скорее ускореения пользователей — стоит поиграться с TCP congestion алгоритмами (Netflix написали свой оптимизированый для видео и их склиентов: cc_netflix) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)
Если бы у вас были интерактивные штуки, а не видео, то было бы интересно поиграться с buffer bloat (sch_fq, tsq, bql, etc).
Есть такой чувак, Jordan Zimmerman. В 2009 году он решил вести блог, который будет разоблачать жидомассонский заговор популярные заблуждения в архитектуре приложений. Написал много смелых мыслей про зло систем сборки (надо собирать только RAD-ом), unit тесты (QA должен работать, а не перекладывать свою работу на программистов), комментарии (если нужны комментарии — значит код -гавно) и DI.
Потом, конечно, со стыда потёр всё. Такие дела.
Спасибо за отличную подборку. Если позволите добавлю свои 5 копеек. Есть отличные ребята из JUG.ru / CodeFreeze которые помимо встреч JUG и CodeFreeze делают еще ряд крутых технических конференций:
Делегирую другие задачи. Часто пишу в дороге, когда всё равно нечего делать. Не играю в компьютерные игры.
Важно научиться печатать со скоростью внутреннего диалога. Ну и выбрать клавиатуру, которая не мешает это делать.
Всем интересующимся темой управления советую прослушать набор подкастов под названием Manager Tools Basics. Подкасты на английском, но простом и внятном.
Есть также отличный сайт Manager Tools Podcast Explorer, на котором все подкасты сгруппированы по категориям и есть поиск.
Вкратце:
4 основных инструмента: 1:1, обратная связь, коучинг и делегирование. Каждый из них проработан целиком и полностью, начиная от «зачем нужен» и заканчивая «а что делать, если...». Самое ценное в них, на мой взгляд, то, что по каждому инструменту чётко расписан алгоритм того, КАК его применять и почему именно так.
Например, по 1:1:
1. Проводится раз в неделю, с каждым своим непосредственным подчинённым. Если подчинённых много — раз в две недели, но не реже.
2. Проводится всегда в одно и то же время. Соответственно, придётся строить своё расписание вокруг ваших 1:1. Про то, как это делать, есть отдельные подкасты.
3. Время начала согласовывается так: пишется письмо всем, в котором описан ваш вариант расписания. Далее он уточняется с каждым индивидуально.
4. Продолжительность — 30 мин. Первые 10 минут вы говорите о том, что интересует подчинённого, вторые — о том, что интересует вас, третьи — о будущем подчинённого в компании. На практике, обычно последняя десятиминутка растворяется в первых двух.
5. Результаты 1:1 записываются на отдельном листке (формат есть на сайте) и затем применяются вами в дальнейшей работе.
6. Если ваш начальник не понимает, зачем вам нужные 1:1 с подчинёнными в таком формате, ему говорится что-то вроде «Плох тот менеджер, который не может уделить своему подчинённому полчаса в неделю»
+1,
зашел в комментарии именно это написать.
Двенадцать лет назад, когда у меня был магазин компьютерной техники, лоток на радиобазаре и самая продвинутая спамилка городской доски объявлений в виде моего горячо любимого партнера — мы готовились к новогодним скидкам недели за три. Поднимали цену в полтора-два раза, потом спустя две недели скидывали немного, потом еще через неделю еще пару процентов скидывали. За неделю до НГ в наглую опять поднимали, а 29-31 цены поднимались до изначального завышенного положения.
Норма прибыли при этом поднималась раза в два, потому что оптовики поступали точно так-же, так что если бы с ноября не делались запасы на все доступные оборотники, одолженные деньги и т.п., то прибыльность даже падала бы… Но понятное дело на всё не запасешься, что-то всё равно покупалось, так что сильно не раскачаешься. Помню как 31 декабря мне поставщик за Самсунговский монитор зарядил цену выше розницы. На САМСУНГ, у которого вообще цены с тройным дном были! И ведь никуда не денешься, пришлось брать :)
Если так в среднем прикинуть, то техника на новогодние скидки клиентам выходила на 20-50% дороже чем без скидок.
Не знаю как сейчас, пару лет назад столкнулся с тем, что хоть в среднем скидки на НГ по прежнему означают повышение цен, но я уже перестал угадывать когда они повышаются и насколько… вроде как стало менее лживо, но не скажу. Полноценный датамайнинг не делал.
К сожалению, очень часто говоря про «финансовую сферу и высокие нагрузки» начинают с придыханием рассказывать про какие-нибудь много-мегабайтные каркасы, библиотеки и иснтрументы, при этом вообще не понимая азов: как они устроены изнутри, почему и на каких принципах они работают. Инстументы это отличная вещь, если вы понимаете как они устроены. Например, зная внутренее устройство DTrace намного проще понимать когда его нужно применять, а когда нет.
Мне казалось, что в анонсе своего доклада на ADD-2011 я достачно полно расклыл суть того, о чем я буду говорить (цитирую): «В докладе пойдет речь о методиках изучения производительности Java приложений без использования готовых сторонних инструментов профилирования, а используя не так широко известные встроенные в JVM возможности (threaddumps, java agents, bytecode manipulation).»
Как это моголо сформировать какие-то ложные ожидания?
Бывает масса случаев когда и язык свой надо написать. Всё зависит от стоящей перед вами задачи. В любом случая, я считаю что каждый обязан знать как именно устроен компилятор, виртуальная машина, и операционная система и в принципе понимать как это можно всё написать. Тогда будет программист будет ценить уже готовые инструменты и понимать в каких случаях их нужно применять.
В этом докладе я не ставил себе целью дать исчерпывающий обзор инструментов профилирования. Их существует великое множество с теми или иными достоинствами и недостатками. Более того, мой доклад не содержал призывов всегда писать свои собственные инструменты, а вот знать каким образом можно получить тот или иной результат, как самому написать профилировщик того или иного типа должен каждый программист. Только тогда можно оценить тот или иной инструмент, понять что именно этот инструмент замеряет, где его сильные и слабые свойства.
Я, кстати говоря, уже давно не задаю на собеседовании сложны, алгоритмических, либо практических вопросов, например напишите пожалуйста самый простой неблокирующий стек. Мы примерно час общаемся на интересные, в первую очередь для нас, темы, такие как: многопоточность и сихронизация, память и сборка мусора. Иногда разбираем какие-либо интересные, опять же для нас, проблемы с которыми сталкивались мы или соискатель. Такой разговор по большей части дает понять что из себя представляет человек, что знает, чем умеет пользоваться а о чем слышит впервые.
И опять же, если я задаю вопрос, то стараюсь формулировать его так, что бы соискатель не пытался вспомнить какую-нибудь конкретную вещь, а рассказал то, что знает. Например вопрос «какие три вида синхронизации применяются при использовании synchronized», я сформулирую примерно так: «что вы можете рассказать о ключевом слове synchronized», и при необходимости задать некоторые уточняющие вопросы, например «а чем он отличается от локов, кстати, каких именно, из пакета juc»
забыл: пару вопросов о GC, о загрузке классов, было просил написать свою реализацию gc: представим что GC у JVM нет, человек должен был сделать некий super-class для всех обьектов, и должен был быть «личным» gc для них.
Потом попросил его сделать анализ работы этого GC с профайлером и пояснить почему он так работает.
ЗЫ: это был очень сильный соискатель и было очень приятно с ним говорить, потому и писали такую интересную вещь.
Задаю вопросы о production-мониторинге. Что и как нужно отслеживать в продакшене. Разок когда дал кусок кода написанного в моей команде и попросил в течении 3 часов разобраться как он работает и там где считает нужным расставить мониторинговые вызовы(дал в руки библиотеку metrics)
Зы: вопросы которые я задаю Junior не сильно отличаются от тех что Senior. Просто ожидаю разный уровень ответов.
Теория — пару вопросов из этого списка, чуть под настроение(вычеты, сортировки, перестановки, графы, древья: чтото базовое что можно вывести на месте) и разные вопросы на многопоточность:
как устроен CopyOnWriteArrayList. Зачем он так устроен?
Когда имеет смысл паралелить алгортм(хорошо если знает закон Амдала)?
Прошу написать принципы реализации многопоточных списков и кольцевого буфера. а неблокирующие?
Прошу придумать как бы он реализовывал многопоточный HashMap в случае разных паттернов работы с ним.
Как бы он реализовал кеш для приложения? а персистентный?
Как можно остановить поток выполняющий код который не находится под нашим контролем?
Из чего состоит переключение контекста процессора между потоками и процессами? сколько оно стоит?
Когда не знает ответа на вопрос(или даже не понимает формулировки) поясняю ему вопрос, я хочу увидеть как он мыслит.
После прошу написать реалию минимального приложения, тоже под настроение и в зависимости от диалога: последние варианты были написать сервис быстро возвращающий среднее в массиве(то есть к нему по сети приходят запросы «добавить елемент a» и «верни среднее»). На задачку даю часа 3-4. Для этого даю ему некий костяк — интерфейс который он должен реализовать и интерфейсы которыми он может пользоваться. Сам быстренько реализую последние.
Тут смотрю как они пишет тесты и mock-реализации(и пишет ли), пишет ли комментарии, как структурирует код. Обычно я наблюдаю что это спрашивают устно, но ИМХО в таких вопросах устный ответ часто в корни разнится от реальности.
UFO landed and left these words here
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Больше половины из поиска (срез за последние 30 дней). Это люди, которые что-то ищут, им нужно какое-то решение, но не развлечение. У развлекательных сайтов другой паттерн и источники трафика.
Вот еще один график, о котором мы говорили. У Хабра очень лояльная аудитория. К октябрю доля тех, кто возвращается, будет в районе 75% (в статистике есть август, многие еще были в отпусках).
Но может вам поможет такое сравнение — PostCSS — это как Babel 6 (который с плагинами и может делать всё что угодно, а не только ES6), только для CSS. У PostCSS даже есть cssnext, который как раз «CSS4» делает.
Посещаю эту конференцию с 2004 года каждый год (мне ехать недалеко) и раньше было как-то более конкретно всё, презентовались действительно сложные вещи и докладчики были все очень компетентные.
Последние годы наблюдаю что конфа сползает из общения увлечённых техникой гиков в площадку для пиара разных проектов.
Много раз уже предлагали делать предварительное голосование на сайте чтобы выявить популярность докладов и правильно распределить аудитории. Но нет, политика взяла и в этом году верх.
В итоге например все презентации по системам виртуализации-докеру-оркестрации проходили в сравнительно небольшой аудитории и примерно такое же количество людей толпилось в коридоре в надежде туда попасть. В то же время я видел полупустой Janson заполненный хорошо если на треть.
Нет, в целом я очень доволен конечно тем что и в этом году там был. Встретился со всеми с кем хотел, всё обсудил.
Для желающих посетить конфу в следующем году советую заранее подготовиться и идти общаться по интересам, это наиболее эффективно.
/sys/class/net/eth*/device/numa_node) и свой набор IP'шников. Далее на вышестоящем балансере (я так пологаю IPVS) считать каждую NUMA-ноду за отдельный хост/proc/sys/vm/zone_reclaim_mode— важно, чтобы оно было выставленно в нольethtool -k(tso, lro,[rt]xcsum, etc) и почти всегда надо задирать ring buffer'а вethtool -glspci -t -vvv(особо важно для 40G+)cc_netflix) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)жидомассонский заговорпопулярные заблуждения в архитектуре приложений. Написал много смелых мыслей про зло систем сборки (надо собирать только RAD-ом), unit тесты (QA должен работать, а не перекладывать свою работу на программистов), комментарии (если нужны комментарии — значит код -гавно) и DI.Потом, конечно, со стыда потёр всё. Такие дела.
.NEXT:
Видео: www.youtube.com/playlist?list=PLtWrKx3nUGBeCTpN--0BsxxM0dFPVMXip
сайт: dotnext.ru
JPoint: www.youtube.com/playlist?list=PLVe-2wcL84b8qDFSA2rpbpuE3OTkEbAwe
сайт: javapoint.ru
Mobius: www.youtube.com/channel/UCG70q1HRspLdd93HW94WS-A/videos
сайт: mobiusconf.com
Ну и собственно:
JUG.ru: www.youtube.com/user/JUGRuVideo
CodeFreeze: www.youtube.com/user/CodeFreezeRU
Важно научиться печатать со скоростью внутреннего диалога. Ну и выбрать клавиатуру, которая не мешает это делать.
Всем интересующимся темой управления советую прослушать набор подкастов под названием Manager Tools Basics. Подкасты на английском, но простом и внятном.
Есть также отличный сайт Manager Tools Podcast Explorer, на котором все подкасты сгруппированы по категориям и есть поиск.
Вкратце:
4 основных инструмента: 1:1, обратная связь, коучинг и делегирование. Каждый из них проработан целиком и полностью, начиная от «зачем нужен» и заканчивая «а что делать, если...». Самое ценное в них, на мой взгляд, то, что по каждому инструменту чётко расписан алгоритм того, КАК его применять и почему именно так.
Например, по 1:1:
1. Проводится раз в неделю, с каждым своим непосредственным подчинённым. Если подчинённых много — раз в две недели, но не реже.
2. Проводится всегда в одно и то же время. Соответственно, придётся строить своё расписание вокруг ваших 1:1. Про то, как это делать, есть отдельные подкасты.
3. Время начала согласовывается так: пишется письмо всем, в котором описан ваш вариант расписания. Далее он уточняется с каждым индивидуально.
4. Продолжительность — 30 мин. Первые 10 минут вы говорите о том, что интересует подчинённого, вторые — о том, что интересует вас, третьи — о будущем подчинённого в компании. На практике, обычно последняя десятиминутка растворяется в первых двух.
5. Результаты 1:1 записываются на отдельном листке (формат есть на сайте) и затем применяются вами в дальнейшей работе.
6. Если ваш начальник не понимает, зачем вам нужные 1:1 с подчинёнными в таком формате, ему говорится что-то вроде «Плох тот менеджер, который не может уделить своему подчинённому полчаса в неделю»
зашел в комментарии именно это написать.
Двенадцать лет назад, когда у меня был магазин компьютерной техники, лоток на радиобазаре и самая продвинутая спамилка городской доски объявлений в виде моего горячо любимого партнера — мы готовились к новогодним скидкам недели за три. Поднимали цену в полтора-два раза, потом спустя две недели скидывали немного, потом еще через неделю еще пару процентов скидывали. За неделю до НГ в наглую опять поднимали, а 29-31 цены поднимались до изначального завышенного положения.
Норма прибыли при этом поднималась раза в два, потому что оптовики поступали точно так-же, так что если бы с ноября не делались запасы на все доступные оборотники, одолженные деньги и т.п., то прибыльность даже падала бы… Но понятное дело на всё не запасешься, что-то всё равно покупалось, так что сильно не раскачаешься. Помню как 31 декабря мне поставщик за Самсунговский монитор зарядил цену выше розницы. На САМСУНГ, у которого вообще цены с тройным дном были! И ведь никуда не денешься, пришлось брать :)
Если так в среднем прикинуть, то техника на новогодние скидки клиентам выходила на 20-50% дороже чем без скидок.
Не знаю как сейчас, пару лет назад столкнулся с тем, что хоть в среднем скидки на НГ по прежнему означают повышение цен, но я уже перестал угадывать когда они повышаются и насколько… вроде как стало менее лживо, но не скажу. Полноценный датамайнинг не делал.
Мне казалось, что в анонсе своего доклада на ADD-2011 я достачно полно расклыл суть того, о чем я буду говорить (цитирую): «В докладе пойдет речь о методиках изучения производительности Java приложений без использования готовых сторонних инструментов профилирования, а используя не так широко известные встроенные в JVM возможности (threaddumps, java agents, bytecode manipulation).»
Как это моголо сформировать какие-то ложные ожидания?
В этом докладе я не ставил себе целью дать исчерпывающий обзор инструментов профилирования. Их существует великое множество с теми или иными достоинствами и недостатками. Более того, мой доклад не содержал призывов всегда писать свои собственные инструменты, а вот знать каким образом можно получить тот или иной результат, как самому написать профилировщик того или иного типа должен каждый программист. Только тогда можно оценить тот или иной инструмент, понять что именно этот инструмент замеряет, где его сильные и слабые свойства.
И опять же, если я задаю вопрос, то стараюсь формулировать его так, что бы соискатель не пытался вспомнить какую-нибудь конкретную вещь, а рассказал то, что знает. Например вопрос «какие три вида синхронизации применяются при использовании synchronized», я сформулирую примерно так: «что вы можете рассказать о ключевом слове synchronized», и при необходимости задать некоторые уточняющие вопросы, например «а чем он отличается от локов, кстати, каких именно, из пакета juc»
Потом попросил его сделать анализ работы этого GC с профайлером и пояснить почему он так работает.
ЗЫ: это был очень сильный соискатель и было очень приятно с ним говорить, потому и писали такую интересную вещь.
Задаю вопросы о production-мониторинге. Что и как нужно отслеживать в продакшене. Разок когда дал кусок кода написанного в моей команде и попросил в течении 3 часов разобраться как он работает и там где считает нужным расставить мониторинговые вызовы(дал в руки библиотеку metrics)
Теория — пару вопросов из этого списка, чуть под настроение(вычеты, сортировки, перестановки, графы, древья: чтото базовое что можно вывести на месте) и разные вопросы на многопоточность:
как устроен CopyOnWriteArrayList. Зачем он так устроен?
Когда имеет смысл паралелить алгортм(хорошо если знает закон Амдала)?
Прошу написать принципы реализации многопоточных списков и кольцевого буфера. а неблокирующие?
Прошу придумать как бы он реализовывал многопоточный HashMap в случае разных паттернов работы с ним.
Как бы он реализовал кеш для приложения? а персистентный?
Как можно остановить поток выполняющий код который не находится под нашим контролем?
Из чего состоит переключение контекста процессора между потоками и процессами? сколько оно стоит?
Когда не знает ответа на вопрос(или даже не понимает формулировки) поясняю ему вопрос, я хочу увидеть как он мыслит.
После прошу написать реалию минимального приложения, тоже под настроение и в зависимости от диалога: последние варианты были написать сервис быстро возвращающий среднее в массиве(то есть к нему по сети приходят запросы «добавить елемент a» и «верни среднее»). На задачку даю часа 3-4. Для этого даю ему некий костяк — интерфейс который он должен реализовать и интерфейсы которыми он может пользоваться. Сам быстренько реализую последние.
Тут смотрю как они пишет тесты и mock-реализации(и пишет ли), пишет ли комментарии, как структурирует код. Обычно я наблюдаю что это спрашивают устно, но ИМХО в таких вопросах устный ответ часто в корни разнится от реальности.