Собран на скорую руку из того что

User
Это перевод достаточно важной статьи про GitLab Flow, альтернативе Git flow и GitHub flow. Статья была написана в 2014, так что скриншоты успели устареть. Тем не менее сама статья более чем актуальна:
Ветвление и слияние веток в git устроено гораздо проще, чем в более ранних системах контроля версий, таких как SVN. Поэтому есть много способов организации командной работы над кодом, и большинство из них достаточно хороши. По крайней мере, они дают много преимуществ по сравнению с тем, что было до git. Но сам по себе git — не серебряная пуля, и во многих командах организация рабочего процесса с git имеет ряд проблем:
Мы хотим представить вам GitLab flow — чётко определённый набор практик, решающий эти проблемы. Он объединяет в одну систему:
Это перевод статьи Ruby (on Rails) ecosystem bittersweet or "we like to hate PHP", написанной 30 мая 2016, т.е. совсем недавно. Я полностью согласен с её автором, и сам давно горел желанием написать что-то подобное в последнее время, но у меня не так много опыта с Ruby, поэтому моя писанина не была бы настолько объективна, как писанина человека, который этот опыт имеет, и имеет его в хорошем количестве. А тут на тебе: всё в одном месте уже собрано, и мысли прямо один в один как у меня. Грех не перевести на русский. Также, статья вообще очень хороша как небольшой набор объективного и беспристрастного анализа двух языков современной веб-разработки. В общем, далее — перевод слов автора.
многобукв; нечитал;
В этой статье я рассказываю о некоторых фактах и персональном опыте для того чтобы доказать, что PHP в данный момент живее, конкурентоспособнее, а также имеет менее связанную экосистему, чем Ruby. Я говорю о Производительности, Синтаксисе и Аспектах кодинга, Сообществе и Инструментарии разработчика.
Здравствуйте. Сегодня я расскажу как можно создать единый установочный носитель с множеством разных версий Windows не прибегая к использованию стороннего ПО. Таким образом вы будете полностью понимать какие манипуляции мы выполняем.
Также я сделаю упор на то, чтобы как можно меньше энтропии привносить в этот мир изменять структуру оригинальных установочных дистрибутивов.
Кому интересно — прошу под кат.
Каждый раз поднимая новый сервер в облаках, вы получаете случайный IP-адрес. Не все понимают, что IP-адрес может попасть к вам с "историей". Часто приходится тратить время на удаление IP из публичных черных списков. В моём случае в последний раз это была очень неторопливая переписка с mail.ru, которая ни к чему не привела. После этого, создав новый сервер, я задумался: как же сделать так, чтобы не огребать проблем с такими IP-адресами?
Наверное все уже и так знают, что всегда хорошо иметь большой и сложный пароль. Многие так же знают про менеждеры паролей и как удобно, а главное безопасно можно хранить в них информацию.
По специфике моей работы мне часто приходится записывать и хранить большое количество паролей и другой конфиденциальной информации, поэтому я пользуюсь Keepass2 — менеджером паролей со свободной лицензией. Я не стану рассказывать о его возможностях и преимуществах перед другими, все это и так уже обсуждалось не раз. Если кто хочет познакомиться подробнее, вот несколько ссылок: wiki, обзорная статья, сравнения с другими: 1 2.
Вместо этого я хотел бы рассказать об одной его интересной функции:
Функция называется "URL Overrides", и представляет ссобой возможность запускать ассоциированные с записями программы и передавать им данные для аутентификации прямо из Keepass'а.
Например, вы можете хранить в keepass'е список учеток для подключения к удаленному серверу, а в определенный момент выбрать нужную и простым нажатием Ctrl+U, запустить клиент удаленного подключения, и моментально получить доступ к вашему серверу.
Это очень удобно, так как все логины и пароли не хранятся абы где, а надежно зашифрованны в вашей базе keepass и передаются программе-клиенту только в момент подключения.
Идея состоит в том, что бы использовать Keepass как единую точку входа на все удаленные сервера.
Наверно, в мире данных нет подобного феномена настолько неоднозначного понимания того, что же такое Hadoop. Ни один подобный продукт не окутан таким большим количеством мифов, легенд, а главное непонимания со стороны пользователей. Не менее загадочным и противоречивым является термин "Big Data", который иногда хочется писать желтым шрифтом(спасибо маркетологам), а произносить с особым пафосом. Об этих двух понятиях — Hadoop и Big Data я бы хотел поделиться с сообществом, а возможно и развести небольшой холивар.
Возможно статья кого-то обидит, кого-то улыбнет, но я надеюсь, что не оставит никого равнодушным.
Демонстрация Hadoop пользователям