GitHub *

Cегодня Dash наконец открыл исходный код ПО «dashvend», на котором работает концепт — аппарат по продаже газировки (вызвавший фурор на последней Биткойн-конференции в Майами). Теперь желающие могут создавать собственные вендинговые устройства на базе технологии мгновенных платежей Dash InstantX (эта технология уже поддерживается в мобильных кошельках Dash).

На этот раз я бы хотел предложить к прочтению [вольный] перевод статьи Тома Престон-Вернера, одного из сооснователей GitHub, в которой он рассуждает о том, какие выгоды компания может извлечь из открытия своих проектов, какие проекты открывать не стоит и какова Единственно Правильная Лицензия. Хочу также отметить, что мнение переводчика не всегда совпадает с мнением автора оригинала. Ссылка на оригинал, как всегда, под текстом перевода.

Когда Крис и я начинали работу над GitHub в конце 2007, мы разделили работу на две части. Крис работал над Rail-приложением, а я работал над Grit, первым в истории адаптером Git для Ruby. После шести месяцев разработки, Grit стал достаточно законченным, чтобы обслуживать GitHub во время нашего публичного запуска сайта и мы встали перед интересным вопросом:

Стоит ли нам открыть исходники Grit или оставить его проприетарным?

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

Я видел много проектов, где конфигурация подкладывается в файловую систему в виде properties/json/xml файлов с непостижимыми уму переоределениями в момент загрузки. И что же на самом деле использует приложение становится ясно только после просмотра лог файлов компонента либо во время отладки.

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

Вообще лирическое вступление было навеяно вполне конкретной историей про сломанный гитхаб. Сделанная на заре одного из проектов синхронизация домашнего репо в гитхаб решила проблему переезда. Потом про костыль забыли. Древнее зло уснуло и терпеливо ждало своего часа. В один прекрасный день скайнет новый сотрудник решил привести в порядок тот самый домашний репозиторий. И самым популярным вопросом среди программистов в тот день было «коллега, а вы не видели мою ветку 0022? ну такая, с багфиксами». Руководство опс-тим было спокойно как никогда: гит — это распределенная система, версия кода хранится на персональном компьютере каждого разработчика. Давайте уже как-нибудь разберитесь между собой и не отвлекайте нас от сборки наших ядер и тюнингов сетевых стеков.

И все же зачем..?

Действительно, можно нафантазировать большое количество количество возможных проблем, например:

• Недоступность удаленного репозитория и отсутсвие актуальной локальной копии
• Злоумышленники с помощью украденного пароля испортили/удалили репозитории
• Ошибки в манипуляциях с репозиториями

Итак, что и как бэкапить...

Open Source проекты с каждым днём набирают всё большие обороты, появляются новые, активно развиваются популярные.
Такие проекты как Bootstrap, Angular.js, Elasticsearch, Symfony Framework, Swift и многие другие привлекают новых разработчиков, их сообщество растёт. Всё это даёт огромный рост проектам, а самим разработчикам интересно поучаствовать в разработке чего-то, чем пользуется весь мир.

Я, как и многие другие программисты, не устоял и также время от времени участвую в разработке Open Source проектов, в основном на PHP. Но когда я начинал, я столкнулся с проблемой — я не знал, как правильно организовать процесс «контрибьютинга», с чего начать, как сделать так, чтобы мой Pull Request рассмотрели и т.д.

Всем начинающим «контрибьютерам», которые столкнулись с похожим проблемами, добро пожаловать под кат.

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

Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.

Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.

После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.

В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.

Мы в «Латере» занимаемся созданием биллинга для операторов связи. В блоге на Хабре мы не только рассказываем об особенностях нашей системы и деталях ее разработки (например, обеспечении отказоустойчивости), но и публикуем материалы о том, как другие компании работают с ИТ-инфраструктурой. Сегодня мы представляем вашему вниманию адаптированный перевод заметки главного разработчика Azure Джеффа Уилкокса, о том, как более двух тысяч членов команды проекта переезжали на GitHub.

За последние четыре года Azure очень многое перенял от opensource-сообщества, поэтому нам пришлось пересмотреть подходы к работе и минимизировать количество выполняемых вручную операций, необходимых для поддержания крупной GitHub-организации. Мы автоматизировали большую часть управленческих функций, создав веб-приложение с открытым исходным кодом, которое использует некоторые из сервисов Azure (это App Service, Active Directory и Azure Storage), GitHub API и другие свободно распространяемые решения.

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

Разработчики и организации любых размеров сразу почувствуют, насколько может быть полезным наш портал: Azure Active Directory дает инженерной группе доступ к инструментам для работы с GitHub.



Веб-портал, созданный с использованием Azure, GitHub API и Node.js, позволяет автоматизировать работу с GitHub и ускорить адаптацию новых сотрудников.

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

Привет, Хабр! В этой статье речь пойдет о таком не очень приятном аспекте машинного обучения, как оптимизация гиперпараметров. Две недели назад в очень известный и полезный проект 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
• картинки и анимашки по вкусу

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

Вчера Github объявил о добавлении AWS Educate в набор бесплатно предлагаемых инструментов и сервисов для студентов. Отныне все студенты, зарегистрированные в программе Github Education, получают в пользование такие инструменты как: БД, cloud-computing, анализ данных и многое другое.

В рамках программы предоставляется доступ к учебной информации, включающей в себя: лабораторные / домашние работы и портал для студентов. Каждый студент получает 35$ (100$ для вузов, зарегистрированных в программе) + бонус в размере 15$ от github, которые можно потратить на оплату счетов AWS. Итого можно получить до 115$ гранта.

Получить грант можно здесь (для зарегистрированных в программе github education)

Подробнее про aws educate почитать тут


Также Github напоминает о своей программе стажировок в Сан-Франциско.

Найден быстрый и бесплатный способ решения проблемы сетевой установки GitHub for Desktop for Windows.

Суть в том, во время установки в Windows GitHub for Desktop использует S3 Amazon services, и технологию ClickOnce, однако при установке у меня часто возникали разрывы соединения, зависания, при которых установка продолжалась с ошибкой.

И решение было найдено!

      Сталкивались ли вы когда нибудь с долгим поиском документации к используемой библиотеке или пакету? Я считаю странным, что исходный код не распространяется с пользовательской документацией. Ведь она такая же важная часть кода, как тесты или зависимости. Без хорошей пользовательской документации мы можем «убить» уйму времени на анализ кода и комментариев. Так почему бы не хранить пользовательскую документацию вместе с исходными кодами программы? Речь не о 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, возникает вопрос, как кормиться (а желательно, и разбогатеть!), большую часть времени занимаясь свободными проектами.

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

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

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

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

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

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

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