Расскажите, кстати, если это не покрыто NDA, про необычные удачные решения в организации внутренней работы. В частности, «пайпы» — что-то похожее на нестандартное; например, может быть есть какая-нибудь крутая agile-методология для ревью, распределения задач итп?
Друг, Amazon, Air, Shopfans Express, посредник по сумме взял чуть меньше 100$, доставка заняла неделю, еще 4 дня шло по США и компоновалось у посредника
Безусловно, Go не функциональный язык, и всего богатства параметрического полиморфизма там нет. Однако, если интерфейсы Go сравнивать с generic'ами в каком-нибудь C# или Java, то значительное количество кейсов использования generic'ов последних легко реализуется в рамках Go, что хорошо видно, например, по реализации кучи в стандартной библиотеке Go.
Всегда есть случайные шумы, и чем больше людей тем это заметнее. В кабинетах заметно проще это минимизировать.
По простаивает, мы же не о джуниорах говорим, не о немотивированных разработчиках, и не о 5-минутных задачах — иначе всегда есть чем полезным заняться на время ожидания ответа.
Наушники генерируют шум, который хотя бы не выводит из потока, и в ряде случает эффективно настраивает на работу. Хотя насчёт полной тишины для максимального сосредоточения невозможно не согласиться (если, к сожалению, речь не о менеджере, принимающем решение об устройстве офиса)
По исследованиям, есть известное исследование о влиянии музыки на креативность (убивает почти полностью), про опенспейсы ряд исследований провели авторы Peopleware, плюс там же есть ряд ссылок на прочие исследования.
Вы не поверите, в шумном опенспейсе реальное общение нередко заменяется общением в мессенджере — быстрее, удобнее, и почти всегда устроит не-моментальный ответ, тогда как физически отвлекать человека в наушниках несколько неправильно.
В Go работа с интерфейсами весьма близка к generic'ам, и их мощность хорошо видна даже по стандартной библиотеке, где, например, везде где можно используются io.Reader'ы и io.Writter'ы
Весьма хорошо, что разработчики постепенно понимают важность удобного написания и исполнения параллельного кода и корутин, и выходят новые удобные инструменты для этого. Конкуренция в таких вещах положительно влияет на удобство и возможности (<joke>и демонстрирует фанатам node.js его ущербность</joke>)
Судя по статье и документации, Rust — это чуть более человечный Erlang. Те же immutable структуры, попытки минимизировать использование shared state посредством мучений разработчиков при их использовании, и всякие приятные вещи типа pattern matching'а.
С другой стороны, есть Go. Помимо его очевидного недостатка (Not invented here), и перекладывания на разработчика ответственности за целостность shared state, он даёт гораздо больше возможностей для работы, чтобы называть его языком более высокого уровня, чем Rust, при сохранении удобства и эффективности параллельного исполнения кода и использования памяти (ну и, само собой, не мучает разработчика immutable переменными, отсутствием необходимых структур типа ассоциативных массивов, и прочими ограничениями).
<offtop>
Знаю команду одного очень успешного it-проекта, которая неожиданным образом следует принципу DRY: копипастят код исключительно друг друга (и друг на друга ссылаются в случае проблем со свежескопированным кодом).
</offtop>
По сути, основной принцип один: нужно писать код, соответствующий общей идеологии проекта, и, по возможности, поддержка которого не вызывает желание убить автора. Бывают скрипты, которые нужно написать быстро, которые используются одним способом, и требования к которым не меняются годами. Бывают задачи типа «максимально быстро запилить эксперимент/прототип, чтобы не жалко было выбросить». В таких случаях рабочий императивный говнокод вида «поток сознания» вполне пригоден и полностью соответствует идеологии задачи, и, более того, нередко хорошо поддаётся рефакторингу.
Логично. Проблема в том, что после этого разработчик мог бы просто смержить в свою ветку мастер/релиз и таким образом легко разрешить конфликт. А так, придётся угадывать ветку, с которой произошёл конфликт, мержиться с ней, и всё равно иметь проблемы в случае отката ребейзом любой из этих веток.
Например, разработчик может сам разрешать конфликты, поскольку лучше понимает функционал, чем релиз-инженер. Вообще же, замена функционала итп часто обратно несовместима, и на дев-платформах это легко разрешать банальным мержем с мастером/релизом.
Помимо этого, схема с ребейзом непригодна для отката мержа, дошедшего до мастера-продакшена, и в ряде случаев всё равно быстро можно будет сделать только реверт или ребейз, а последний в этом случае заведомо вызовет непредсказуемые проблемы.
>Владислав Чернов: Мы используем git rebase, мы именно его используем, потому что git revert нас не устраивает, так как мы разрабатываем каждую задачу в отдельной ветке. Если мы откатываем с помощью revert после сливания ветки релиза и ветки мастера, то разработчику придётся делать revert на revert, поэтому мы используем git rebase. Мы моментально откатываемся, соответственно, собираем новую сборку и выкладываемся на стейджинг.
Признайте честно, что просто не осилили git revert и cherry-pick. В результате, например, разработчикам под страхом страшной смерти нельзя мержится от ветки, к которой ещё могут запустить git rebase.
Статья по актуальной теме, написана неплохим языком, и без явно антинаучной бредятины — это хорошо. К сожалению, на этом положительные качества статьи заканчиваются. Судя по всему, это последствия написания статьи мягко говоря гуманитарием без технической редактуры.
Особо неприятное:
1. Формула E=mc^2 не имеет непосредственного отношения к увеличению инерциальной массы тела при увеличении скорости. Для этого есть формула m = m0 / (1 — v^2/c^2). Это основы СТО (т.е. школьный курс физики), без знания которых очень странно писать такие статьи.
2. По wormhole'ам текст недалёк от псевдонаучных статей. Технически, wormhole'ы — непротиворечащая физике особенность топологически склеенного пространства-времени — это не «существование обосновано». Например, точно так же не противоречит физике существование тахионов (сверхсветовых частиц, нарушающих причинно-следственную связь), магнитных монополей и прочей экзотики — и это совершенно не означает, что они действительно существуют в нашем мире.
3. Не перечислен ряд прочих перспективных двигателей типа ионного.
> Ошибка! Не удалось подключиться к базе данных. Проверьте правильность реквизитов доступа в файле /cms/kernel/config.inc.php.
Если верить гуглу, это S.Builder CMS. Хайлоад!
www.zabbix.com/img/zabconf2013/presentations/Which_Database_is_Better_for_Zabbix.pdf
По простаивает, мы же не о джуниорах говорим, не о немотивированных разработчиках, и не о 5-минутных задачах — иначе всегда есть чем полезным заняться на время ожидания ответа.
По исследованиям, есть известное исследование о влиянии музыки на креативность (убивает почти полностью), про опенспейсы ряд исследований провели авторы Peopleware, плюс там же есть ряд ссылок на прочие исследования.
Судя по статье и документации, Rust — это чуть более человечный Erlang. Те же immutable структуры, попытки минимизировать использование shared state посредством мучений разработчиков при их использовании, и всякие приятные вещи типа pattern matching'а.
С другой стороны, есть Go. Помимо его очевидного недостатка (Not invented here), и перекладывания на разработчика ответственности за целостность shared state, он даёт гораздо больше возможностей для работы, чтобы называть его языком более высокого уровня, чем Rust, при сохранении удобства и эффективности параллельного исполнения кода и использования памяти (ну и, само собой, не мучает разработчика immutable переменными, отсутствием необходимых структур типа ассоциативных массивов, и прочими ограничениями).
Посмотрим, что из этого выйдет.
Знаю команду одного очень успешного it-проекта, которая неожиданным образом следует принципу DRY: копипастят код исключительно друг друга (и друг на друга ссылаются в случае проблем со свежескопированным кодом).
</offtop>
По сути, основной принцип один: нужно писать код, соответствующий общей идеологии проекта, и, по возможности, поддержка которого не вызывает желание убить автора. Бывают скрипты, которые нужно написать быстро, которые используются одним способом, и требования к которым не меняются годами. Бывают задачи типа «максимально быстро запилить эксперимент/прототип, чтобы не жалко было выбросить». В таких случаях рабочий императивный говнокод вида «поток сознания» вполне пригоден и полностью соответствует идеологии задачи, и, более того, нередко хорошо поддаётся рефакторингу.
Помимо этого, схема с ребейзом непригодна для отката мержа, дошедшего до мастера-продакшена, и в ряде случаев всё равно быстро можно будет сделать только реверт или ребейз, а последний в этом случае заведомо вызовет непредсказуемые проблемы.
Кстати, привет 2 хейтерам из Баду.
Признайте честно, что просто не осилили git revert и cherry-pick. В результате, например, разработчикам под страхом страшной смерти нельзя мержится от ветки, к которой ещё могут запустить git rebase.
Особо неприятное:
1. Формула E=mc^2 не имеет непосредственного отношения к увеличению инерциальной массы тела при увеличении скорости. Для этого есть формула m = m0 / (1 — v^2/c^2). Это основы СТО (т.е. школьный курс физики), без знания которых очень странно писать такие статьи.
2. По wormhole'ам текст недалёк от псевдонаучных статей. Технически, wormhole'ы — непротиворечащая физике особенность топологически склеенного пространства-времени — это не «существование обосновано». Например, точно так же не противоречит физике существование тахионов (сверхсветовых частиц, нарушающих причинно-следственную связь), магнитных монополей и прочей экзотики — и это совершенно не означает, что они действительно существуют в нашем мире.
3. Не перечислен ряд прочих перспективных двигателей типа ионного.