Совсем недавно Гугл потерял кучу моих фото. Судя по спец форумам, это происходит часто:
https://productforums.google.com/forum/#!topic/photos/QuKiYjKCXPM
https://productforums.google.com/forum/#!topic/photos/bNSFIy0Mx0Q
https://productforums.google.com/forum/#!msg/photos/7Xf0Cj6_ixU/1JbVu4fbCAAJ
https://productforums.google.com/forum/#!topic/maps/njdwFPaqSeo
Вполне понятно зачем Гугл толкает такую мысль: им выгодно, чтобы люди перелезали с десктопа в облако и начинали платить Гуглу. Попугают вирусами, глядишь продажи Хромбуков подрастут.
Фреймворки дают задаче ещё одну степень свободы. Можно начинать дискутировать не только на тему JavaScript или Java, а на более сложную: JavaScript+Angular vs Java/Vaadin. Ваш выбор усложнился в разы.
Я думаю, что можно отойти назад и посмотреть не на производительность программистов, а на шанс успеха проекта. Сможем-ли мы найти нужного разработчика, столкнемся-ли мы с неожиданными проблемами? Большее удобство от фреймворка/языка может обернуться невозможностью расширения или критической проблемой, на фикс которой уйдут месяцы. А менее удобный, но проверенный рецепт позволит решить задачу быстрее.
Можно взять пример фирму PayPal, разработчики которой в 2013 году очень хвалили Node.JS, что технология позволила им ускорить время ответа сервера с 300 до 200 мс, что у них выросла производительность людей в два раза. https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/ Сейчас в блоге посты про squbs (Scala). Логично предположить, что если бы Node.JS давал обещанную скорость реализации проекта, он был бы у них везде. Чисто по экономическим соображениям. Но они продолжают искать и пробовать новые инструменты и возвращаются к старым. Видно, что не так все радужно с Node.JS. Ускоряя что-то, теряешь в других местах.
Тут недавно был шутливый, но отчасти правдивый пост про Docker. С ним тоже возникает вопрос удешевляет-ли он на самом деле разработку и поддержку ПО. Статья хоть и была шутливая, но проблема в ней — реальная. Докер не всегда делает проекты успешнее и дешевле. О том сколько проблем он с собой приносит есть неплохой доклад Андрея Турецкого с Highload++: https://www.youtube.com/watch?v=UgUuF_qZmWc
Microsoft Natural с проводами имеет отлично расположенные клавиши. Жаль, выпускать перестали. Когда сломалась пришлось уже беспроводную покупать и она без нампада.
Только чтобы в Хабре на комментарий ответить:)
Даже в Хроме для перехода на другой адрес в той же вкладке не нужно мышку трогать, а уж в IDE и подавно.
"A" переводит курсор в конец строки и активирует режим ввода. После завершения набора нажатием [ESC] вы можете нажать '.' где угодно, чтобы повторить ввод в конце строки.
Может быть вы знаете зачем? Чем лучшем, чем нажать Home/End в обычном редакторе?
Очень тяжело отвыкать от моментальной компиляции в паре с hot-swap. Поправил код, переключился в браузер, а там уже новая версия. Вот это все очень затягивает.
Я зря второй абзац написал. Хотел пояснить мысль и только больше запутал. Я имел в виду, что Pivotal использует готовую виртуальную машину, сервлет контейнер и библиотеку для создания Spring и продажи сопутствующих сервисов. Oracle добавляет async api в servlet container за свой счёт и от этого выигрывают другие компании. При этом выигрыш самого Oracle мне не очень понятен.
Я имел в виду, что Pivotal использует готовую виртуальную машину, сервлет контейнер и библиотеку для создания Spring и продажи сопутствующих сервисов. Аналогично поступает Lightbend.
JetBrains и JRebel пользуется популярностью платформы и продают инструменты для разработки. У той же Intellij Idea поддержка фреймворков JavaEE — это основное отличие бесплатной и платной версий.
В то же время насколько велик вклад этих компаний в разработку JavaEE?
Мне кажется, что сейчас большую выгоду получают вендоры доп. продуктов: JetBrains, Pivotal, JRebel, Lightbend, IBM.
Фирма Oracle, оплачивающая большую часть разработки остаётся в стороне. Было бы разумно, если бы Pivotal или IBM взялись за поддержку фреймворка.
Кто-то должен заниматься развитием языка и виртуальной машины. Если это развитие остановится, Spring постепенно умрёт. Даже сейчас Java как язык сильно отстаёт от конкурентов, хотя виртуальная машина по-прежнему хороша.
Также появятся проблемы у десктоп приложений на JavaFX и Swing. С каждой новой версией операцинной системы будет отваливаться часть функционала, который никто не будет фиксить. Новых проектов также никто не рискнет писать на FX или Swing.
JavaScript код остается в текстовом виде. JS один из языков, для которых JIT компилятор эффективнее, чем AOT-компиляция. JIT-компилятор видит как исполняется блок кода и может перекомпилировать его "на лету" в случае необходимости. Написать оптимизирующий AOT-компилятор JS крайне затруднительно из-за самого языка программирования.
Virtual DOM нужен для того, чтобы код шарился бежду браузером и нативом. Т.е. у вас остается практически тот же код в браузере и на устройстве.
А смысл? Я уже и так знаю, что на него реакция есть :)
Отдали хорошим знакомым. Уже большой стал. Иногда играем.
У меня также: в сумме 3 раза делался тест на собак — все негативные. 3 дня с псом дома и абсолютно недышащий нос.
У Москвы есть большое преимущество — жена может найти себе работу. Город огромный, разных вариантов трудоустроиться — полно.
JavaCritical_ функции, к сожалению, не работают на Windows:
https://bugs.openjdk.java.net/browse/JDK-8167408
Фикс отложен до JDK 10.
https://productforums.google.com/forum/#!topic/photos/QuKiYjKCXPM
https://productforums.google.com/forum/#!topic/photos/bNSFIy0Mx0Q
https://productforums.google.com/forum/#!msg/photos/7Xf0Cj6_ixU/1JbVu4fbCAAJ
https://productforums.google.com/forum/#!topic/maps/njdwFPaqSeo
Теперь я на облако так слепо не полагаюсь.
Фреймворки дают задаче ещё одну степень свободы. Можно начинать дискутировать не только на тему JavaScript или Java, а на более сложную: JavaScript+Angular vs Java/Vaadin. Ваш выбор усложнился в разы.
Я думаю, что можно отойти назад и посмотреть не на производительность программистов, а на шанс успеха проекта. Сможем-ли мы найти нужного разработчика, столкнемся-ли мы с неожиданными проблемами? Большее удобство от фреймворка/языка может обернуться невозможностью расширения или критической проблемой, на фикс которой уйдут месяцы. А менее удобный, но проверенный рецепт позволит решить задачу быстрее.
Можно взять пример фирму PayPal, разработчики которой в 2013 году очень хвалили Node.JS, что технология позволила им ускорить время ответа сервера с 300 до 200 мс, что у них выросла производительность людей в два раза. https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/ Сейчас в блоге посты про squbs (Scala). Логично предположить, что если бы Node.JS давал обещанную скорость реализации проекта, он был бы у них везде. Чисто по экономическим соображениям. Но они продолжают искать и пробовать новые инструменты и возвращаются к старым. Видно, что не так все радужно с Node.JS. Ускоряя что-то, теряешь в других местах.
Тут недавно был шутливый, но отчасти правдивый пост про Docker. С ним тоже возникает вопрос удешевляет-ли он на самом деле разработку и поддержку ПО. Статья хоть и была шутливая, но проблема в ней — реальная. Докер не всегда делает проекты успешнее и дешевле. О том сколько проблем он с собой приносит есть неплохой доклад Андрея Турецкого с Highload++: https://www.youtube.com/watch?v=UgUuF_qZmWc
Она. Здорово, что снова появилась.
Microsoft Natural с проводами имеет отлично расположенные клавиши. Жаль, выпускать перестали. Когда сломалась пришлось уже беспроводную покупать и она без нампада.
Только чтобы в Хабре на комментарий ответить:)
Даже в Хроме для перехода на другой адрес в той же вкладке не нужно мышку трогать, а уж в IDE и подавно.
Может быть вы знаете зачем? Чем лучшем, чем нажать Home/End в обычном редакторе?
Для каких переменных используется именование с подчеркиванием на конце? Например, valuesmutex.
Очень тяжело отвыкать от моментальной компиляции в паре с hot-swap. Поправил код, переключился в браузер, а там уже новая версия. Вот это все очень затягивает.
Я зря второй абзац написал. Хотел пояснить мысль и только больше запутал. Я имел в виду, что Pivotal использует готовую виртуальную машину, сервлет контейнер и библиотеку для создания Spring и продажи сопутствующих сервисов. Oracle добавляет async api в servlet container за свой счёт и от этого выигрывают другие компании. При этом выигрыш самого Oracle мне не очень понятен.
Я имел в виду, что Pivotal использует готовую виртуальную машину, сервлет контейнер и библиотеку для создания Spring и продажи сопутствующих сервисов. Аналогично поступает Lightbend.
JetBrains и JRebel пользуется популярностью платформы и продают инструменты для разработки. У той же Intellij Idea поддержка фреймворков JavaEE — это основное отличие бесплатной и платной версий.
В то же время насколько велик вклад этих компаний в разработку JavaEE?
Мне кажется, что сейчас большую выгоду получают вендоры доп. продуктов: JetBrains, Pivotal, JRebel, Lightbend, IBM.
Фирма Oracle, оплачивающая большую часть разработки остаётся в стороне. Было бы разумно, если бы Pivotal или IBM взялись за поддержку фреймворка.
Кто-то должен заниматься развитием языка и виртуальной машины. Если это развитие остановится, Spring постепенно умрёт. Даже сейчас Java как язык сильно отстаёт от конкурентов, хотя виртуальная машина по-прежнему хороша.
Также появятся проблемы у десктоп приложений на JavaFX и Swing. С каждой новой версией операцинной системы будет отваливаться часть функционала, который никто не будет фиксить. Новых проектов также никто не рискнет писать на FX или Swing.
Доки по JavaScriptCore говорят об обратном: http://trac.webkit.org/wiki/JavaScriptCore
Предполагаю, что дока по React Native устарела. Действительно, до iOS8 JIT был доступен только для Safari. Однако с релизом iOS 8 компилятором обзавелся и WKWebView: http://developer.telerik.com/featured/why-ios-8s-wkwebview-is-a-big-deal-for-hybrid-development/
Предполагаю, что и JavaScriptCore мог им обзовестись.
JavaScript код остается в текстовом виде. JS один из языков, для которых JIT компилятор эффективнее, чем AOT-компиляция. JIT-компилятор видит как исполняется блок кода и может перекомпилировать его "на лету" в случае необходимости. Написать оптимизирующий AOT-компилятор JS крайне затруднительно из-за самого языка программирования.
Virtual DOM нужен для того, чтобы код шарился бежду браузером и нативом. Т.е. у вас остается практически тот же код в браузере и на устройстве.