GitHub *

Привет, Хабр! В этой статье речь пойдет о таком не очень приятном аспекте машинного обучения, как оптимизация гиперпараметров. Две недели назад в очень известный и полезный проект Vowpal Wabbit был влит модуль vw-hyperopt.py, умеющий находить хорошие конфигурации гиперпараметров моделей Vowpal Wabbit в пространствах большой размерности. Модуль был разработан внутри DCA (Data-Centric Alliance).

Для поиска хороших конфигураций vw-hyperopt использует алгоритмы из питоновской библиотеки Hyperopt и может оптимизировать гиперпараметры адаптивно с помощью метода Tree-Structured Parzen Estimators (TPE). Это позволяет находить лучшие оптимумы, чем простой grid search, при равном количестве итераций.

Эта статья будет интересна всем, кто имеет дело с Vowpal Wabbit, и особенно тем, кто досадовал на отсутствие в исходном коде способов тюнинга многочисленных ручек моделей, и либо тюнил их вручную, либо кодил оптимизацию самостоятельно.

Программирование — процесс творческий и часто желание написать кусок кода или сиюминутно исправить ошибку становится просто невыносимым. Иногда написания кода требуют внешние обстоятельства, как то критичная ошибка в коде, которая валит проект. Для сотрудников, занимающих руководящие позиции в команде, нужна возможность провести code review и поправить проблемные участки кода.

Хорошо когда в пределах досягаемости есть стационарный компьютер или ноутбук на котором развернута привычная среда разработки. Но что делать если вы находитесь за пределами рабочего места? Таскать с собой постоянно ноутбук? Но во первых большой 13-15 дюймовый ноутбук не везде развернешь (например общественный транспорт), а во вторых таскать его постоянно с собой — еще то занятие. Можно конечно купить 11 дюймовый MacBook Air (или его аналог), но все равно он будет не настолько компактен и не так часто используем, чтобы оправдать покупку.

Чтож, обратим свой взор на устройства, которые сейчас практически всегда с нами — это телефон и планшет. Телефон — это конечно вариант экстремальный, хотя сейчас, с появлением 6 — 6,5 дюймовых моделей, грань между телефоном и планшетом стирается. У меня есть опыт успешного восстановления удаленного сервера по ssh с телефона iPhone 4s с 3.5 дюймовым экраном. Но мы все таки говорим о процессе полноценной работы с кодом, поэтому, на мой взгляд, минимальным является планшет с диагональю от 7 дюймов, экран которого вмещает сопоставимое с экраном большого компьютера, информации. Я покажу на примере iPad Mini возможные варианты его использования для решения повседневных задач разработчика.



Если вас заинтересовала тема — читаем дальше (осторожно, большое количество картинок).

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

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


Та ну, тут же всё опирается в реакцию и слепой набор чисел

Вы несколько лет писали свой проект и теперь хотите привлечь пользователей? У меня есть простой, как холостяцкая яичница с беконом, рецепт специально для вас.

Для приготовления простого сайта вам понадобится:

• репозиторий на GitHub — 1 штука
• готовый html шаблон, для придания приятного вида — 1 штука
• кусочек свежего компилирущегося C++ кода — минимум 1 строка кода
• готовые javascript соусы из магазина — ~500Kb
• картинки и анимашки по вкусу

Меняйте любые компоненты, экспериментируйте и готовьте свои сайты для любимого языка!

      Сталкивались ли вы когда нибудь с долгим поиском документации к используемой библиотеке или пакету? Я считаю странным, что исходный код не распространяется с пользовательской документацией. Ведь она такая же важная часть кода, как тесты или зависимости. Без хорошей пользовательской документации мы можем «убить» уйму времени на анализ кода и комментариев. Так почему бы не хранить пользовательскую документацию вместе с исходными кодами программы? Речь не о DocBlock и генерацию документации по API проекта, я говорю именно о пользовательской документации, которую мы так любим за последовательное повествование и множество примеров.

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

Многим статья может показаться «капитанской». Если вы почувствуете на своих щеках соленые брызги и услышите шум волн, немедленно прекратите чтение!

Сегодня наше внимание привлекла удивительная история человека, который поддерживает язык программирования SPITBOL. Его история насчитывает несколько десятилетий.

Краткое содержание

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

Однако услуги сторонних переводчиков стоят денег. Хуже того — наш контент бурлит программированием и математикой, поэтому годится не любой переводчик.

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

Я попробую рассказать о том решении к которому мы пришли, а именно:

• как мы дешево-сердито использовали github для пользовательских переводов
• как специфика сайта мешает при переводе
• насколько реально получить помощь от пользователей
• как отметить переводы для поисковика Google
• наконец, насколько виден (или не виден) эффект от переведенного контента

За подробностями добро пожаловать под кат!

Многие пользуются Slack, Twitter и видели такие штуки:

Как это работает и как такое сделать самим?

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

Мы наблюдаем бум свободных проектов. В основном, благодаря Гитхабу. 23 декабря 2013 года на сервисе был создан 10-миллионный проект. К 23 декабря 2015 года количество проектов более чем утроится: прямо сейчас на Гитхабе 28 миллионов проектов.

Многих привлекает идея свободности, потому что она перекликается с идеей «улучшения мира», как основной мотивации продуктивной деятельности человека.

Но так как обычная работа программистов в конторах очень далека от open source, возникает вопрос, как кормиться (а желательно, и разбогатеть!), большую часть времени занимаясь свободными проектами.

Судя по последним вопросам на Тостере, у людей много ожиданий, но мало понимания в этой области. Поэтому я решил написать это эссе.

Само по себе выкладывание проекта не является улучшением мира

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

Вы выложили код. Чем вы помогли экономике в этот момент? Ничем, поэтому и миру вы пока ничем не помогли.

Ваш проект может спасать людей от рака, быть бесплатным, экономить миллионы долларов, и при этом быть закрытым.

Сконцентрируйтесь не на том, чем вообще полезен ваш проект, а чем полезна его свободность.

Синергетический эффект свободного кода

Менеджер многопоточных закачек на GO.

http://loafter.github.io/godownloader/
https://github.com/Loafter/godownloader

Вступление

Давным-давно, в году этак 1998, для выхода в интернет я использовал модем на работе у отца. Он его включал вечером после работы и я мог наслаждаться просторами сети интернет на скорости аж 31.2 кбит/c. В то время не было истеричных блогеров, страницы не весили по мегабайту, а в новостных сайтах говорили только правду. Естественно основной интерес представляли ресурсы. Картинки, программы, всякие дополнения к играм, вроде машинок. Как сейчас помню качать через IE было сущим адом. Скачать файл весом больше 500 кб было просто невозможно, древний осел был намного упрямей.

Что это и зачем оно надо: Как известно, главное преимущество Java мира в том в нем существует огромное количество open-source проектов на на все случаи жизни, однако найти нужный на github'e не так просто, так как описание проекта часто мало информативно, зачастую сложно даже понять этот проект для Android'a или нет. В этой статье я автоматически и полуавтоматически собрал Java проекты, убрал старые и проекты только для Android'a, выбрал 350 набравших больше всего звезд, разделил по категориям и перевел описания.

Если вы хотите убедиться что базы данных пишут не только на C, найти проекты для работы с большими данными или нейронными сетями, пишите свой язык программирования для JVM и хотите посмотреть как это уже сделано или же просто хотите узнать какие новые возможности можно найти в Java мире open-source то это статья вам, думаю, может пригодится.


Другие статьи серии: часть 1. JPA и Hibernate в вопросах и ответах

Update: Внимание, актуальная версия со много большим количеством ссылок, находиться теперь в моем github'e проекте useful-java-links, по этой ссылке.

Всем привет!

Недавно команда rust_book_ru закончила перевод книги «The Rust Programming Language» на русский язык.



Когда я только присоединился к проекту перевода, начатого kgv, нам несколько раз говорили: «Вы делаете перевод на GitHub? Странные вы, для краудсорсинг-перевода есть другой сервис — вот ссылка». Мы не стали переходить на другие сервисы и в итоге это решение полностью оправдалось.

Я хочу рассказать о том, почему мы всё же разместили книгу на GitHub и почему даже переводчику полезно быть немного программистом.

Гитхаб — великолепный агрегатор репозиториев и инструмент для коллективной работы. К сожалению, многие возможности конфигурирования на стороне сервера (вроде коммит хуков) остаются недоступными. Но ситуация постепенно меняется в лучшую сторону.

Случилось то, чего многие ждали довольно долго. А именно: недавно была анонсирована фича, под названием protected branches, которая позволяет настроить правила работы с ветками в рамках репозитория. Да, теперь можно запретить force push в master!

Под катом скриншоты и выдержки из блога разработчиков.

Доброго дня, Хабр!

Спешу рассказать вам, что совсем недавно вышла новая версия нашего баг-трекера — YouTrack 6.5!



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

Уже довольно долгое время я задаюсь вопросом: «Может ли в наших суровых реалиях жить и развиваться Open Source проект?». Этот вопрос меня периодически тревожит, так как я сам являюсь автором одного такого проекта — WysiBB. Я задавал подобный вопрос на различных ресурсах, были вопросы и на Тостере. Но по сути все сводилось к тому, что в русскоязычном сегменте интернета не работают кнопки «Поддержать проект», «Пожертвовать» и т.д. и развиваться могут только проекты с огромной аудиторией и/или платными функциями.

В чем суть?

Но вот наконец в один прекрасный день, я наткнулся на интересную идею, как можно получать некоторые финансовые вливания в развитие и видеть, какие фичи наиболее востребованы пользователями. Эту идею я увидел на сайте Robomongo(кто не знает, это GUI для MongoDB). И ее суть заключается в следующем: пользователю предоставляется возможность выбрать из списка issues(с джитхаба) наиболее его тревожащую и пожертвовать средства на ее доработку. Когда пользователь делает пожертвование, рейтинг приоритетности этой фичи повышается. Так автор проекта получает средства на свой кошелек и видит какие фичи имеют наивысший приоритет(больше всего пожертвований) и соответственно являются наиболее востребованными. Автор приступает к их разработке в первую очередь, проект развивается, а пользователь получает долгожданную фичу. Мне эта идея понравилась и я решил реализовать подобный механизм на своем проекте, а когда начал работу над этим сервисом, понял что такой сервис может быть полезен не только для меня. Так появился на свет GitFund.

Привет, Habrahabr!
Наша компания известна прежде всего своими решениями в области информационной безопасности. Мы выпускаем такие продукты, как электронные идентификаторы Рутокен и электронные ключи для защиты софта Guardant.
Обычно наши статьи носят сугубо технический характер, но на этот раз речь пойдет о нашей внутренней системе учета социальных выплат для сотрудников.

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

Андрей Глазков, Ито Хаято из Google, а также другие специалисты на Github работают над составлением спецификации Shadow DOM. Уже проделана огромная работа, однако еще много предстоит сделать. В рамках поддержки работы на этом направлении создан перевод существующей версии спецификации от 7 июля.

Эта спецификация описывает способ объединения нескольких DOM-деревьев в одну иерархию, и взаимодействие этих деревьев друг с другом в одном документе, что позволяет построить DOM более правильно.

Git — штука не то чтобы особо сложная, но гибкая. Иногда эта гибкость приводит к забавным последствиям. К примеру, посмотрите на этот коммит на GitHub. Он выглядит как нормальный коммит, но если вы клонируете себе данный репозиторий, то такого коммита в нем не найдете. Потому что это потерянный коммит, более известный как git loose object или же orphaned commit. Под катом — немного про внутренности Git, откуда такое берется и что делать, если оно вам встретилось.

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

Изменить что-то за один миг — необычайно сложная задача

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



До появления нашего сервиса, сложно было сравнивать простой ChangeLog с блогом, поскольку не было способа подписаться на обновления. Ведь ссылку на rss фид блога можно закинуть в rss читалку, на соцпрофиль можно подписаться, зафолловив человека, а подписаться на изменения библиотеки было сложно.