Ruby/Rails таки еще не мертв но перспектив развития особо нет и через какое-то время умрет
Про то, что rails плох — пусть хотя-бы один пхп фреймворк будет настолько плох и он станет лучшим пхп фреймвоком из существующих. Серьезно, планка поднята очень высоко и не смотря на серьезные архитектурные проблемы rails все еще живее всех живых
Да даже упомянутый asset pipeline — какие фреймворки из коробки имеют настроенный сборщик ассетов? Ведь оно все равно надо а настраивать это не так тривиально (нужные разные правила для разных окружений, надо уметь hot reload в дев, source maps etc) — зачем тратить тысячи человекочасов на повтор такого раз за разом. Рельсы берут такими вот мелочами — когда за тебя решены вопросы которые все равно придется решать
Про то, что переходить некуда — уже есть. Зовется Phoenix (язык — elixir). Делают люди из команды rails. И таки разработчики на него уже переходят т к все основные проблемы рельс успешно решены. Всячески рекомендую.
Насколько мне известно, проблема в реализации указанного в статье только одна — cache poisoning.
Именно из-за этого хэш использется только для проверки целостности и никак иначе
оф дока: www.w3.org/TR/2014/WD-SRI-20140318/#risks-1
Биткоины же ;) И оборот у них уже выше WU.
Но конечно с конвертацией туда-сюда проблемы. Но если прижмут остальные платежки (собственно уже в процессе) то будет вполне себе вариант
* Ruby/Rails никуда не уходят, до сих пор адекватный инструмент решения многих задач. Конкурентов особо нет. Впрочем, пик развития недавно прошел.
Цитата из статьи:
> Ruby перестает быть модным, но продолжает быть эффективным инструментом для построения стартапов
* Go никаким боком не конкурент хотя часто используется совместно — для нагруженных участков
* Многие опытные разработчики сейчас переходят с рельс на Elixir/Phoenix (сюрприз, написанные людьми из команды рельс — с исправлением накопленных за годы развития косяков).
Гляньте phoenix/elixir — язык функциональный, неизменяемые переменные, pattern matching и т д.
Но вот по ощущениям пишется как на рельсах ;)
И все равно что там ооп или фп. Конечно, код отличается, для разных языков совсем по разному структурирование программы происходит, если следовать идеологии языка то все замечательно (шутка про программиста на фортране пишущего на фортране на любом языке). Но вот подход «взял и пользуешься» точно такой же как в рельсах.
Собственно кроме phoenix и rails я ничего даже близко подобного не видел, не зависимо от языка
> User.create(params[:user])
>…
> код «под капотом» чрезвычайно сложен
От сложности никуда не деться, все что перечислено всеравно надо делать. И если сделать вместо одной «ручки» россыпь то код проще не станет. Более того, с россыпью появляется новая проблема: а все ли ручки дернуты.
> Как бы там ни было, я покидаю Ruby
Основной вопрос — а куда? Несмотря на свой почтенный возраст рельсам существует крайне мало альтернатив. Могу вспомнить только elixir/phoenix — кстати от людей из команды rails. И там, кстати, решены многие вопросы упомянутые тут (возможность переписать фреймворк с нуля развязывает руки, да)
Да, проблема такая есть. И ее решение нетривиально. Собственно, та же проблема и с приватными e2e сообщениями почти везде, включая телеграм — нет хорошего способа узнать что публичный ключ действительно принадлежит собеседнику а не какому-то третьему лицу.
Решения есть но не сильно удобные.
Пример решения: программа-клиент генерирует сигнатуру на основе публичного ключа(ключей). это может быть картинка, текст и т д.
потом эти сигнатуры сверяются через любой сторонний канал (голосом по телефону например). Телеграм делает именно так, но они выбрали очень плохую визуализацию, пример: https://telegram.org/img/key_image.jpg
лучше бы там была случайно-бредовая текстовая фраза — ее хоть голосом можно передать
Не буду вступать в длинную переписку, скажу что вы совершенно перепутали симметричные и асимметричных методы шифрования.
см комментарий выше, там расписано (если цитат недостаточно указана ссылка на полную статью). Обычная гибридная схема, такая в ssl/https используется, ничего нового. при помощи публичного ключа шифруется сгенерированный секретный ключ, а уже им шифруется (aes, симметрично) основной текст. расшифровывается тоже обычно — при помощи приватного ключа достаем секретный ключ, им расшифровываем основной текст. кстати — в такой схеме нет необходимости хранить несколько копий основного тела сообщения
Это усложняет протокол, но решаемо — достаточно шифровать исходный текст разными публичными ключами, по числу устройств пользователя. насколько мне известно эпловский iMessage работает именно так.
Синхронизация — есть, история — есть, мультиустройства — есть, end-to-end — есть, оффлайн сообщения — есть.
P.S. случайная ссылка из гугла: http://techcrunch.com/2014/02/27/apple-explains-exactly-how-secure-imessage-really-is/
Your public keys are sent to Apple’s servers. Your private keys are stored on your device. Apple never sees your private keys.
When someone starts an iMessage conversation with you, they fetch your public key(s) from Apple’s servers. Before that message leaves the sender’s device, it’s encrypted into something that only your device knows how to decrypt.
… You’ve actually got one set of keys for each device you add to iCloud, and each iMessage is encrypted independently for each device. So if you have two devices — say, an iPad and an iPhone — each message sent to you is actually encrypted (AES-128) and stored on Apple’s servers twice. Once for each device. When you pull down a message, it’s specifically encrypted for the device you’re on.
Я вот чего не понимаю — по примеру телеграма это как? У телеграма нет end-to-end шифрования. Точнее есть, но только в специальном приватном режиме, использовать который постоянно мало кто будет (на это видимо и расчет).
Хранить можно и на диске, зарезервировав сколько-там места, например 50МБ. Хранение не у всех конечно. и не у определенного числа пользователей — данные не просто режутся на дольки а создается большое число частей — с избыточностью. скажем, при избыточности 3х у нас получается 30 долек — из которых любых 10 достаточно для получения точной копии. 20 нод из 30 могут уйти оффлайн. избыточность и количество частей можно подобрать. Гарантии оно не дает конечно но вероятность ухода оффлайн всех нод одновременно если N большое достаточно мала.
Не вечно? А сколько тогда? И т.д.
Достаточно просто решается введением времени жизни на уровне протокола. Сразу обещаем что оффлайн живет неделю скажем. Это все-таки IM.
P.S. существуют распределенные децентрализованные системы, хранящие так информацию (см maidsafe, storj.io)
Никто не говорит что это просто. Это возможно.
Хранить в DHT сети (при условии что это часть протокола конечно)? Т е данные размазаны по куче разных клиентских устройств. Но имхо лучше так хранить вещи вроде списка контактов, метаинформации
Считаем:
емкость батареи: 2.5Ач х 3.7В = 9.25 Втч
делим на время заряда (четверть часа) — получаем мощность зарядки 37Вт
читаем описание: "технология работает как с MicroUSB" — т е напряжение 5В.
Делим, получаем ток 7.4 ампера.
Ничего так зарядка выходит. Примерно ноутбучная по мощности
José Valim — http://contributors.rubyonrails.org/ — #5 по количеству коммитов.
Пусть будет не "в команде" а core contributor тогда
Про то, что rails плох — пусть хотя-бы один пхп фреймворк будет настолько плох и он станет лучшим пхп фреймвоком из существующих. Серьезно, планка поднята очень высоко и не смотря на серьезные архитектурные проблемы rails все еще живее всех живых
Да даже упомянутый asset pipeline — какие фреймворки из коробки имеют настроенный сборщик ассетов? Ведь оно все равно надо а настраивать это не так тривиально (нужные разные правила для разных окружений, надо уметь hot reload в дев, source maps etc) — зачем тратить тысячи человекочасов на повтор такого раз за разом. Рельсы берут такими вот мелочами — когда за тебя решены вопросы которые все равно придется решать
Про то, что переходить некуда — уже есть. Зовется Phoenix (язык — elixir). Делают люди из команды rails. И таки разработчики на него уже переходят т к все основные проблемы рельс успешно решены. Всячески рекомендую.
Да, все так. Но в статье они не используются или я что-то пропустил?
Имя вида
:chat_roomоно ведь просто в коде написаноИменно из-за этого хэш использется только для проверки целостности и никак иначе
оф дока: www.w3.org/TR/2014/WD-SRI-20140318/#risks-1
Но конечно с конвертацией туда-сюда проблемы. Но если прижмут остальные платежки (собственно уже в процессе) то будет вполне себе вариант
```
pan = pan
|> grease
|> flour
oven = oven
|> preheat(«175C»)
dough = mix(«flour», «baking soda», «salt»)
cake_mixture = mix(«butter», «white», «sugar»,«brown sugar»)
|> beat_until_fluffy
|> beat_mixed_with(«eggs»)
|> mixed_with(«bananas»)
|> mixed_with(:alternating, «buttermilk», dough)
|> mixed_with(:chopped, «walnuts»)
cake = cake_mixture
|> place_on(pan)
|> put_in(oven)
|> wait_for(«30min»)
|> eject
|> put_on(:towel)
|> wait_until_cool_down
```
Как видим, вся последовательность операций линейна и понятна. Может быть это «недостаточно функционально»? Пофиг, главное что удобно на практике.
P.S. |> это pipe operator, работает так:
a |> b |> c ==> c(b(a()))
* Ruby/Rails никуда не уходят, до сих пор адекватный инструмент решения многих задач. Конкурентов особо нет. Впрочем, пик развития недавно прошел.
Цитата из статьи:
> Ruby перестает быть модным, но продолжает быть эффективным инструментом для построения стартапов
* Go никаким боком не конкурент хотя часто используется совместно — для нагруженных участков
* Многие опытные разработчики сейчас переходят с рельс на Elixir/Phoenix (сюрприз, написанные людьми из команды рельс — с исправлением накопленных за годы развития косяков).
Но вот по ощущениям пишется как на рельсах ;)
И все равно что там ооп или фп. Конечно, код отличается, для разных языков совсем по разному структурирование программы происходит, если следовать идеологии языка то все замечательно (шутка про программиста на фортране пишущего на фортране на любом языке). Но вот подход «взял и пользуешься» точно такой же как в рельсах.
Собственно кроме phoenix и rails я ничего даже близко подобного не видел, не зависимо от языка
>…
> код «под капотом» чрезвычайно сложен
От сложности никуда не деться, все что перечислено всеравно надо делать. И если сделать вместо одной «ручки» россыпь то код проще не станет. Более того, с россыпью появляется новая проблема: а все ли ручки дернуты.
> Как бы там ни было, я покидаю Ruby
Основной вопрос — а куда? Несмотря на свой почтенный возраст рельсам существует крайне мало альтернатив. Могу вспомнить только elixir/phoenix — кстати от людей из команды rails. И там, кстати, решены многие вопросы упомянутые тут (возможность переписать фреймворк с нуля развязывает руки, да)
Решения есть но не сильно удобные.
Пример решения: программа-клиент генерирует сигнатуру на основе публичного ключа(ключей). это может быть картинка, текст и т д.
потом эти сигнатуры сверяются через любой сторонний канал (голосом по телефону например). Телеграм делает именно так, но они выбрали очень плохую визуализацию, пример: https://telegram.org/img/key_image.jpg
лучше бы там была случайно-бредовая текстовая фраза — ее хоть голосом можно передать
см комментарий выше, там расписано (если цитат недостаточно указана ссылка на полную статью). Обычная гибридная схема, такая в ssl/https используется, ничего нового. при помощи публичного ключа шифруется сгенерированный секретный ключ, а уже им шифруется (aes, симметрично) основной текст. расшифровывается тоже обычно — при помощи приватного ключа достаем секретный ключ, им расшифровываем основной текст. кстати — в такой схеме нет необходимости хранить несколько копий основного тела сообщения
Синхронизация — есть, история — есть, мультиустройства — есть, end-to-end — есть, оффлайн сообщения — есть.
P.S. случайная ссылка из гугла:
http://techcrunch.com/2014/02/27/apple-explains-exactly-how-secure-imessage-really-is/
Достаточно просто решается введением времени жизни на уровне протокола. Сразу обещаем что оффлайн живет неделю скажем. Это все-таки IM.
P.S. существуют распределенные децентрализованные системы, хранящие так информацию (см maidsafe, storj.io)
Никто не говорит что это просто. Это возможно.
Длиннопост, TL;DR: Как обычно, замешано бабло. И core разработчики играют на стороне "зла". Личное мнение: Это такой способ замедлить рост bitcoin насколько это возможно. Просто прекратить разработку, сказать "все закончилось, ребята — расходимся" — не получится. Это таки опенсорс.
В википедии: https://en.wikipedia.org/wiki/USB#USB_Power_Delivery
емкость батареи: 2.5Ач х 3.7В = 9.25 Втч
делим на время заряда (четверть часа) — получаем мощность зарядки 37Вт
читаем описание: "технология работает как с MicroUSB" — т е напряжение 5В.
Делим, получаем ток 7.4 ампера.
Ничего так зарядка выходит. Примерно ноутбучная по мощности