Очень нужна ссылка на статью и код Насти Яниной! Комбинирование регуляризаторов и подбор весов — это самое сложное и самое крутое, полезное в ARTM, а документации нифига нет про это. См. мою статью — про это жалуюсь. Банально как в CLI задавать декорреляцию — без чтения кода непонятно.
Как всегда. Если хочется действительно интересного, незаежженного — то только идти в стартап остается. Учитывая критическую нехватку специалистов по data science и big data, компании идут на совсем отчаянные шаги. Мне кажется, со временем градус нездорового хантинга будет только расти.
Думаю, виной всему неправильное толкование корреляции «контрибьютит в открытые проекты» <=> «хороший профессионал». Перепутана причина и следствие. Те кто контрибьютит как правило профессионалы, но не каждый профессионал контрибьютит. Конечно, есть исключения.
Ну а при прочих равных, если выбирать, кого увольнять, то у человека с прокаченным Гитхабом должно быть больше шансов остаться.
Для меня становится испытанием изучение некоторых новых технологий. В каждой я вижу кучу минусов, изъянов (для себя лично), порой до сильной неприязни и рвотных позывов. В таких случаях «ломаю» себя, насильно заставляя ковыряться. Из последнего — Go. Язык чертовски был не по душе. А сейчас уже видимо «стокгольмский синдром» и могу на нем писать, и благодаря нему в том числе нашел отличную новую работу, на митапе даже выступал!
P.S. особенно «хипстерские» технологии раздражают, и тоже себя ломаю. За них платят деньги.
Черт, TOML… Ничему питонистов жизнь не учит. Когда CPython решали на какую систему контроля версий переезжать, тоже было несколько вариантов, все тщательно обсудили и выбрали… то что выбрали. И теперь закономерно огребли проблем и (ура! 2016 год на дворе) решили все-таки переехать на GitHub. Думаю, и здесь глядишь через год-другой формат поменяют на JSON/YAML когда окажется что никто его не использует.
P.S. я сам питонист.
Пример так себе. Во-первых, в Питоне круче делать через cffi, во-вторых, там hello world а не обертка, полторы функции. А сборщик мусора? А сложные объекты? А всякие тонкости про которые никто не пишет как решать? Так что приходите, обещаю fun.
Полностью согласен, хотел написать то же самое!
Нам тоже кажется, что просто стандартные методы найма не очень эффективные и все большему числу компании это становится очевидно. Уж пардон за рекламу, к примеру моя компания анализирует код с гитхаба и посылает «письма счастья» самым крутым контрибьюторам насчет подходящих вакансий, и это очень хорошо работает.
Кое-какие практики спорны, я к примеру раньше часто сталкивался с «environment hell», когда для того чтобы заставить систему из нескольких программ заработать, нужно определить парочку «магических» переменных окружения. Особенно может доставить проблем постоянное изменение PATH, приводящее к путанице с несколькими совпадениями, которые «выстреливают». Так что для себя я всегда стараюсь фиксировать минимально необходимый PATH, а остальное вызывать по относительным/абсолютным путям. Кстати, npm решил эту проблему очень элегантно: npm run «script» запускает скрипт, прописанный в scripts у package.json.
Также я всегда использую свой GOPATH для каждого Go-проекта, так же как и virtualenv для каждого Python-проекта, ибо это единственный способ надежно проверять зависимости.
Gerrit очень хорошо поддерживает все возможные модели. Кнопка Rebase там была сколько я его помню. Но у него есть один существенный минус — по одному комиту на ревью, а если отправлять merge, то не виден кумулятивный diff (таск заведен давно, но воз и ныне там). Такие ограничения сильно бьют по количеству пользователей.
Ну и всякие вот такие комментарии. Коллеги подсказывают что glibc интенсивно пользуется sbrk. Ситуация двоякая выходит — с одной стороны советуют не пользоваться, с другой — много реализаций malloc-а используют.
Я имел в виду (цитата из мана Linux) Avoid using brk() and sbrk(): the malloc(3) memory allocation package is the portable and comfortable way of allocating memory. И еще (цитата из мана Darwin) The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management. На маке вдобавок sbrk еще и кастрированый, выделяет не больше 4 Mb за раз.
Кроме действительно интересных лекций отмечу обилие бесплатной пиццы в обед :) В итоге, насмотрелся после таких мероприятий, как у Mail.ru внутри и решил сменить место работы. Все правильно делаете.
Без вашей помощи, без сильной реакции, это может привести только к одному, и мы сейчас находимся в опасной близости от такого результата: другие браузеры тоже начнут поддерживать/внедрять префикс -webkit-*, превращая экспериментальный вариант реализации функции в новый всеобщий стандарт. Таким образом, единственная реализация станет мировой монополией. Ещё раз. Это уничтожит нашу процедуру принятия стандартов. Здесь не может быть иного варианта, вопрос только в сроках, когда это произойдёт.
Тот же русский Veles изначально под OpenCL затачивался, и цель у проекта была очень похожа на дообучение, инфраструктуру и т.п. Но по опыту, на обычных архитектурах вроде Intel или Nvidia OpenCL всегда проигрывает на таких задачах проприетарным специализированным технологиям в разы и применять его я бы не стал.
Может, макбуки и ломаются реже, но когда они ломаются по пустякам — приходится менять чуть ли не половину макбука. К примеру, на моем retina 2013 разболтались петли передней крышки — проблема типичная, «я не так его закрываю» потому что. Два мастера в разных фирмах заявили что надо менять всю крышку вместе с экраном, вебкамерой и т.д. Это тысяч 30-40 рублей. Из-за шестерки болтов! Бред же.
Думаю, если сломается впаянная оперативная память, то точно так же заставят менять всю материнскую плату. В этом весь Эппл.
P.S. когда я жаловался знакомым, что макбук начинает заряжаться с 5 раза (буквально, до этого красная лампочка не загорается), мне ответили… правильно, «я не так его заряжаю».
Ну а при прочих равных, если выбирать, кого увольнять, то у человека с прокаченным Гитхабом должно быть больше шансов остаться.
P.S. особенно «хипстерские» технологии раздражают, и тоже себя ломаю. За них платят деньги.
P.S. я сам питонист.
Нам тоже кажется, что просто стандартные методы найма не очень эффективные и все большему числу компании это становится очевидно. Уж пардон за рекламу, к примеру моя компания анализирует код с гитхаба и посылает «письма счастья» самым крутым контрибьюторам насчет подходящих вакансий, и это очень хорошо работает.
Также я всегда использую свой GOPATH для каждого Go-проекта, так же как и virtualenv для каждого Python-проекта, ибо это единственный способ надежно проверять зависимости.
Я имел в виду (цитата из мана Linux) Avoid using brk() and sbrk(): the malloc(3) memory allocation package is the portable and comfortable way of allocating memory. И еще (цитата из мана Darwin) The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management. На маке вдобавок sbrk еще и кастрированый, выделяет не больше 4 Mb за раз.
Думаю, если сломается впаянная оперативная память, то точно так же заставят менять всю материнскую плату. В этом весь Эппл.
P.S. когда я жаловался знакомым, что макбук начинает заряжаться с 5 раза (буквально, до этого красная лампочка не загорается), мне ответили… правильно, «я не так его заряжаю».