Есть люди, которые придумывают концепты, а есть те, кто доводит до ума. Первые версии node.js на практике тоже были полным отстоем. Что за привычка искать везде культ личности? Есть просто парень, который не прекращает генерировать идеи даже после того, как несколько из них оказались успешными.
Как говорится Make it work, make it right, make it fast — нормальное решение выходит с третьего раза. Мне кажется подход Райна к разработке состоит в том, чтобы соединив вместе несколько хорошо зарекомендовавших себя технологий из разных областей, получить новое абсолютно бомбическое решение.
Первым была Node.js, собранная из того, что было: asyncio, libuv, V8, commonjs, streams. Много, что работает, но все сложно. Ацкий комбайн с кучей тех.долга. Как говориться — не пытайтесь повторить.
Dyno это попытка сделать удобный инструмент. Node.js сильно провязан с V8, отсюда проблемы с портированием на другие движки и обновлением рантайма. В Dyno весь такой низкоуровневый интим живёт в отдельном загончике — "ядре" — с которым остальной мир — "юзер спейс" — общается лишь протобуфами. Отсюда полный контроль над IO и вообще всем тем, что делает программа. По аналогии с браузерами, весь API четко специфицирован и доступен через общий объект Dyno. Адресация зависимостей декларируется с помощью URI как в XML, есть возможность контролировать мапинг на физические ресурсы. Встроенный бандлер для сборки приложения в исполняемый файл или модуль, как в go. Тайпскрипт, форматтер кода, куча отладочных флажков и данных — все как любят разработчики.
Ну что им 3 рубля жалко? У них траты на юристов для отработки претензии будут на порядки больше, даже если потребуется лишь переложить бумажку с одного стола на дугой.
Хотя, на первый раз важнее прецедент. Оплачивая пустяковый штраф, компания фактически соглашается с претензией, легитимностью ограничений, фактом нарушения и позицией виновного. Спустя некоторое время, новыми поправками в закон уровень ответственности поднимают на порядки. Но юридически самый сложный этап уже пройден и остаётся лишь извлекать профит.
У пользователя нет возможности самостоятельно выбирать, на чьих территориях могут храниться его персональные данные? В случае нарушений выгодопреобретатель всегда государство?
Получается, что ПД теперь не такие уж персональные, а скорее государственные. Пока гражданам они достаются бесплатно. Но в последствии думаю могут сообразить, чтобы сдавать в аренду.
Вводя ограничения, штрафы и возможности для доступа, правительства фактически национализируют ПД. Кстати, такая интересная тенденция сейчас не только в России, но и других государствах. Просто кампании проводятся под разными предлогами.
Экономика линукса построена на обмене знаниями через программный код. Это узнаваемый бренд с четким позиционированием. В него охотно и почти безальтернативно инвестируют как одиночки, так и мега корпорации. Нет проблем с маркетингом.
Пользователи без соответствующей квалификации и амбиций хотят и могут потреблять, но что в замен? Для них работают иные бизнес модели, основанные на других ценностях, которые те способны предоставить — времени, труде, деньгах, внимании, личных данных. И пусть внутри будет линукс, называться оно будет иначе — habr, steam, алиса и т.п. — маркетинг?
Если null это не валидное значение для name, лучше сообщить об этом явно: private String findUser(@NotNull String name) { Object.requireNotNull(name, "name must not be null"); ... }
Разработчик, вызвавший findUser(null) получит NPE, исправит ошибку в коде и в продакшене такая исключительная ситуация не возникнет ни разу.
Описывать промисы как растянутые во времени процессы, не совсем верно. Промис это абстракция над ситуацией в будущем. Как и для обычных синхронных вычислений, ситацией может быть либо какое-то значение, либо брошенное исключение. Отличие только в том, что при использовании промисов мы не требуем разрешения неопределенности сразу, а готовы надеяться, что это когда-нибудь произойдет.
Wait в английском означает активное ожидание, Await что-либо — ближе к "предполагать", отложив дальнейшее рассуждения до разрешение ситуации. await в js именно так и работает, прерывая выполнение текущей функции и переключаясь на другую задачу, пока данное обещание не разрешится.
Понятия синхронный и асинхронный используются по отношению к потоку вычисления. Синхронные операции согласуются с потоком, т.е. выполняются строго последовательно, одна за другой. Для асинхронных операций синхронизация не требуется. Они могут выполняться как угодно — последовательно, параллельно, когда-нибудь или никогда — не важно.
Есть разные ситуации. В некоторых проектах PR висят сотнями, на которые разработчи не обращают внимания. Где-то автор давно забил на поддержку. Где-то с другой стороны сидят люди за зарплату, у которых есть свой взгляд на вещи и более приоритетные таски.
Ревью это на самом деле затратно. Нередко в PR предлагают кастыли, решающие чьи-то сиюминутные проблемы. Без тестов, без документации. Превращать интервью в менторинг или найти время, чтобы переписать самому? Снизить издержки можно. Для этого надо знакомить потенциальных контрибьютеров с принятыми правилами, архитектурой, вкладываться в документацию. На это опять же нужно время и набор самостоятельных скиллов.
Тесты штука сугубо утилитарная. У меня к ним несколько требований: минимум ложных срабатываний, отлавливать максимум регрессионных ошибок и не мешать рефакторингу кода.
Хотя тесты с моками проще писать, они слишком чувствительны к изменениям в реализации и на длительных промежутках времени классические тесты дают лучший эффект. Неплохой баланс получается, если пользоваться моками лишь на границе систем, а внутренности тестировать классикой.
Могут наверно сделать разные тарифные планы, тем более это согласуется с их стандартами найма персонала в разных странах. На бомж тарифах в поддержке работают удаленщики из третьих стран с диктаторами у власти. На топовых персональные данные будут обслуживать только какие-нибкдь девственницы с кристально чистой родословной, проживающие в радиусе мили от Пентагона.
Это больше похоже на развитие существующего протокола. В РФ сервисы на базе упомянутого в статье RCS уже несколько лет предлагают многие операторы. Например, у МТС это называется MTS Connect.
Хранение знаний в головах прочно привязывает жизнь продукта к команде. Потому, что поддерживать другими ресурсами его нереально. Ребята, которые писали манифест знали, что говорить. Бизнес нашел свой выход. Время от времени ситуация на рынке меняется и продукт сливается вместе с командой. На освободившиеся места нанимаются новые люди и новая улучшенная версия пилится с нуля.
Новички пишут код, а инженеры кто по старше — разрабатывают архитектуру и документацию. Вроде логично. Потом старшие уходяд и их места занимают бывшие новички, с большим опытом написания кода и отсутствием других инженрных навыков.
У Фейсбука уже есть что-то подобное — Opengraph. Это истории про объекты (например страницы сайтов) и события, которые с ними происходят (кто-то лайкнул, кто-то поделился ссылкой и т.п.). Популярная нынче во фронтенд разработке Flux архитектура построена на схожих принципах.
Есть люди, которые придумывают концепты, а есть те, кто доводит до ума. Первые версии node.js на практике тоже были полным отстоем. Что за привычка искать везде культ личности? Есть просто парень, который не прекращает генерировать идеи даже после того, как несколько из них оказались успешными.
Как говорится Make it work, make it right, make it fast — нормальное решение выходит с третьего раза. Мне кажется подход Райна к разработке состоит в том, чтобы соединив вместе несколько хорошо зарекомендовавших себя технологий из разных областей, получить новое абсолютно бомбическое решение.
Первым была Node.js, собранная из того, что было: asyncio, libuv, V8, commonjs, streams. Много, что работает, но все сложно. Ацкий комбайн с кучей тех.долга. Как говориться — не пытайтесь повторить.
Dyno это попытка сделать удобный инструмент. Node.js сильно провязан с V8, отсюда проблемы с портированием на другие движки и обновлением рантайма. В Dyno весь такой низкоуровневый интим живёт в отдельном загончике — "ядре" — с которым остальной мир — "юзер спейс" — общается лишь протобуфами. Отсюда полный контроль над IO и вообще всем тем, что делает программа. По аналогии с браузерами, весь API четко специфицирован и доступен через общий объект Dyno. Адресация зависимостей декларируется с помощью URI как в XML, есть возможность контролировать мапинг на физические ресурсы. Встроенный бандлер для сборки приложения в исполняемый файл или модуль, как в go. Тайпскрипт, форматтер кода, куча отладочных флажков и данных — все как любят разработчики.
Ну что им 3 рубля жалко? У них траты на юристов для отработки претензии будут на порядки больше, даже если потребуется лишь переложить бумажку с одного стола на дугой.
Хотя, на первый раз важнее прецедент. Оплачивая пустяковый штраф, компания фактически соглашается с претензией, легитимностью ограничений, фактом нарушения и позицией виновного. Спустя некоторое время, новыми поправками в закон уровень ответственности поднимают на порядки. Но юридически самый сложный этап уже пройден и остаётся лишь извлекать профит.
У пользователя нет возможности самостоятельно выбирать, на чьих территориях могут храниться его персональные данные? В случае нарушений выгодопреобретатель всегда государство?
Получается, что ПД теперь не такие уж персональные, а скорее государственные. Пока гражданам они достаются бесплатно. Но в последствии думаю могут сообразить, чтобы сдавать в аренду.
Вводя ограничения, штрафы и возможности для доступа, правительства фактически национализируют ПД. Кстати, такая интересная тенденция сейчас не только в России, но и других государствах. Просто кампании проводятся под разными предлогами.
Пользователи без соответствующей квалификации и амбиций хотят и могут потреблять, но что в замен? Для них работают иные бизнес модели, основанные на других ценностях, которые те способны предоставить — времени, труде, деньгах, внимании, личных данных. И пусть внутри будет линукс, называться оно будет иначе — habr, steam, алиса и т.п. — маркетинг?
Если null это не валидное значение для name, лучше сообщить об этом явно:
private String findUser(@NotNull String name) { Object.requireNotNull(name, "name must not be null"); ... }Разработчик, вызвавший findUser(null) получит NPE, исправит ошибку в коде и в продакшене такая исключительная ситуация не возникнет ни разу.
Описывать промисы как растянутые во времени процессы, не совсем верно. Промис это абстракция над ситуацией в будущем. Как и для обычных синхронных вычислений, ситацией может быть либо какое-то значение, либо брошенное исключение. Отличие только в том, что при использовании промисов мы не требуем разрешения неопределенности сразу, а готовы надеяться, что это когда-нибудь произойдет.
Wait в английском означает активное ожидание, Await что-либо — ближе к "предполагать", отложив дальнейшее рассуждения до разрешение ситуации. await в js именно так и работает, прерывая выполнение текущей функции и переключаясь на другую задачу, пока данное обещание не разрешится.
Понятия синхронный и асинхронный используются по отношению к потоку вычисления. Синхронные операции согласуются с потоком, т.е. выполняются строго последовательно, одна за другой. Для асинхронных операций синхронизация не требуется. Они могут выполняться как угодно — последовательно, параллельно, когда-нибудь или никогда — не важно.
Вызвавшие эти дискуссии были точно живыми людьми, а не ИИ конкурентов?
Ревью это на самом деле затратно. Нередко в PR предлагают кастыли, решающие чьи-то сиюминутные проблемы. Без тестов, без документации. Превращать интервью в менторинг или найти время, чтобы переписать самому? Снизить издержки можно. Для этого надо знакомить потенциальных контрибьютеров с принятыми правилами, архитектурой, вкладываться в документацию. На это опять же нужно время и набор самостоятельных скиллов.
Тесты штука сугубо утилитарная. У меня к ним несколько требований: минимум ложных срабатываний, отлавливать максимум регрессионных ошибок и не мешать рефакторингу кода.
Хотя тесты с моками проще писать, они слишком чувствительны к изменениям в реализации и на длительных промежутках времени классические тесты дают лучший эффект. Неплохой баланс получается, если пользоваться моками лишь на границе систем, а внутренности тестировать классикой.
Могут наверно сделать разные тарифные планы, тем более это согласуется с их стандартами найма персонала в разных странах. На бомж тарифах в поддержке работают удаленщики из третьих стран с диктаторами у власти. На топовых персональные данные будут обслуживать только какие-нибкдь девственницы с кристально чистой родословной, проживающие в радиусе мили от Пентагона.
Это больше похоже на развитие существующего протокола. В РФ сервисы на базе упомянутого в статье RCS уже несколько лет предлагают многие операторы. Например, у МТС это называется MTS Connect.
Есть жанры, где треки в альбоме формируют самостоятельное произведение.
Хранение знаний в головах прочно привязывает жизнь продукта к команде. Потому, что поддерживать другими ресурсами его нереально. Ребята, которые писали манифест знали, что говорить. Бизнес нашел свой выход. Время от времени ситуация на рынке меняется и продукт сливается вместе с командой. На освободившиеся места нанимаются новые люди и новая улучшенная версия пилится с нуля.
Есть много структур, для которых можно продумать осмысленное преобразование к промису. В конце концов промис это абстракция над значением (value).
Новички пишут код, а инженеры кто по старше — разрабатывают архитектуру и документацию. Вроде логично. Потом старшие уходяд и их места занимают бывшие новички, с большим опытом написания кода и отсутствием других инженрных навыков.