Pull to refresh
79
0
Send message
Да, ядерная энергетика — это здорово. Только упускаете один момент — ядерного топлива (U, Торий в расчет не беру) в мире очень мало. Есть такая теория, которая называется в западной литературе «peak oil». Она говорит о том, что мы извлекаем из недр нефтепродукты быстрее, чем они восстанавливаются. И что самое важное, мы уже исчерпали больше половины нефтяных запасов.

То же самое и с ураном. Да, может статься, что где-то подо льдами Гренландии нас ждет огромное урановое месторождение, но вероятность этого невелика. Сейчас в целом старые месторождения отработаны более, чем на половину. Новых нет. И если про нефть, газ и уголь говорят, что их хватит лет на 300, то урана — на 50-70.

Остается надеяться, что к тому времени что-нибудь придумают. Но тут у атомной энергетики дела не очень: про те же отходы как говорили лет 50 назад, что потом ученые придумают, что с ними делать, так по сей день и говорят.
Вот далековат я от .NET, поэтому иногда возникает очень странное ощущение. Когда кто-то из дотнетчиков показывает, что, мол, раньше, смотрите, какая прорва кода нужна была, чтобы работало то-то и то-то. Смотришь — и правда простыня кода огромная. А теперь мол, смотрите, как все легко и просто. Смотришь — а там кода, конечно, меньше, но ведь все-равно ж дохрена!

И вот не знаешь, как реагировать: то ли радоваться, то ли печалиться. Видимо, нет предела совершенствованию — всегда все можно упростить еще.

(Относится не только к .NET)
Львиная доля тестинга — Selenium, делает скриншоты, выполняется как по сценариям, так и в fuzzy-режиме.

Если говорить о компонентах, с помощью Mockjax и Jasmine тестим логику без привязки к конкретному HTML. Байндинги не тестим — обычно получается так, что их раз настроил и они работают. В редких случаях байндинги сложновато дебажить, но особых проблем нет: главное — приноровиться.

Тесты запускаются каждый раз во время билда, билд на каждый коммит — команда небольшая и идет всего несколько коммитов в день, так что не напряжно.
Надо статью писать :)

Еще раз скажу, что angular очень хорош, и для меня лично он кажется предпочтительнее и Bacdkbone, и Ember.
> Я правильно понял?

Да, и мне нравится работать с небольшими библиотеками, которые делают что-то немногое, но очень хорошо. Цельная архитектура — это хорошо, когда она к тому же еще и отличная. Но в отношении практики JS в Google я такого сказать не могу — их Closure Library, например, на момент выхода поигрывала с точки зрения модульного подхода YUI, да и работа с DOM очень и очень отставала от jQuery. В результате библиотека не взлетела, не смотря на то, что на ней написаны одни из лучших веб-приложений: Gmail и Google Docs.

Здесь у меня такое же недоверие. Те же теги: все эти ng- не соответствуют духу HTML — там для кастом данных предполагается использование data-атрибутов. Или темплейтинг, который вводит лишний синтаксический мусор. Хотя тут обе библиотеки впереди планеты всей: ни Ember, ни Underscore, ни Mustache и близко не подошли.

Все потому, что Angular и в большей степени Knockout позволяют вводить темплейтинг, не нарушая структуру самого HTML-документа. Тем самым мы можем дать нашу верстку на откуп дизайнеру, потом добавить темплейт-атрибуты, но дизайнер сможет продолжать работу с документом так, как если бы это был статический HTML. Т.е. если он хочет, он может использовать инструменты для верстки, или верстать на «рыбе» — мы его никак не ограничиваем. Это жирный плюс, особенно, если хочется распараллелить работу над UI, и мы в моей команде применяем данный подход на практике. Один человек верстает на рыбе, второй вводит байндинги с мок-данными, третий привязывает вьюмодель к бекенду. И в большинстве случаев мы можем работать параллельно.

Насчет JS. Мне понравился KO своей работой с атрибутами модели. С одной стороны да, запись вида

var viewModel = { // KO
    property: ko.observable(value)
}


несколько длиннее, чем

model.set({property: value}); // BB


Но зато потом, когда мы обращаемся к свойству, мы получим следующее

viewModel.property(); // KO
model.get('property'); // BB


И вроде бы разница небольшая, но при использовании Нокаута у меня в среде разработки или в текстовом редакторе срабатывает автокомплит. Мне самому может и мелочь, а вот ребятам, которые только-только пересаживаются с C# или Java на JavaScript это очень помогает.

К angular мой пример меньше относится, но он тоже не очень дружит с автокомплитом из-за того, что свойства описываются в $scope.

Отличия минимальны и я в общем-то полагался на чутье, когда выбирал Нокаут, но после десятков тысяч строк кода на JS за последний год я все больше убеждаюсь в правильности выбора. В моих глазах преимущества Нокаута следующие:

Для новичка:
— минимум магии (за исключением байндингов, но там у всех она есть)
— минимум концепций для изучения
— простота API

Для середнячка:
— возможность построения сложных цепей зависимостей без особых проблем
— легкость интеграции с UI библиотеками через кастом байндинги

Для команды:
— параллельная работа над разными участками приложения
— возможность одновременной работы над проектом нескольких участников с совершенно разным уровнем подготовки
— низкий порог вхождения для людей, плохо знакомым с JavaScript
AIR — это то же самое, что и SL вне браузера. То же самое — расширенные привелегии в обмен на верификацию.
В теории это можно делать через Silverlight и Adobe AIR. И там, и там необходимо подписывать приложение, чтобы оно имело доступ к нативному коду.
В data url одна проблема — длинна url не может быть больше 2 килобайт. Так что далеко не все картинки таким образом можно передавать.
Это смотря с чем сравнивать. Ember (SC2) в разработке больше двух лет был, а на выходе получили монстра, не предлагающего ничего нового по сравнению с BB и KO.

Angular выглядел очень плачевно, когда я выбирал между ним и Knockout год назад. Сегодня это что-то навороченное, но есть пару моментов:

— Knockout явно не стоял на месте — релиз 2.0 может и содержит немного фич, но ими всеми начинаешь пользоваться постоянно. Очень и очень удачный набор получился.
— куча крафта, который существовал в angular, так там и остается. Я смотрю на него и понимаю, что мне совсем-совсем не хочется иметь с ним дело.
— дружелюбность к REST — это хорошо. Еще б было хорошо, если б сервер писался так, чтобы оставаться дружелюбным к REST. На практике подобное случается редко. Что до конкретного примера, jQuery getJSON в связке с destructurring assignment из ES6/CoffeeScript дают похожий результат.
По пунктам, перечисленным в статье:
— DI. Не знаю, нужно ли это. Автор называет причины: модульность, архитектура, зависимости — тут поможет AMD и динамическая типизация.
— Unit Tests. Никто не мешает писать тесты для того же Ko. Хочешь Jasmine, хочешь — Mocha — пожалуйста.
— e2e. Mockjax спасет отца русской демократии
— сообщество. В гуглогруппе Нокаута тоже полно энтузиастов, чуть что сразу фиддл в студию и решают проблему.
— декларативность. Синтаксис байндитгов и атрибутов Нокаута имо чище и читабельней. Кроме того, data-атрибуты проходят валидацию.
— scopes и watches — в Нокауте есть и работать с ними очень и очень удобно.

В общем, дело обстоит так:
— выбрали Нокаут — оставайтесь, все в порядке.
— еще ничего не выбрали? — попробуйте одно и другое, посмотрите, что вам лично нравится.
Не хочу казаться совсем недалеким человеком, но есть вопрос к людям, понимающим в крипто. Зачем подписывать запросы, если установлено соединение TLS, а пользователь идентифицируется (логины-пароли, sms и прочее)?
Чувство двоякое. С одной стороны, многое из перечисленного было на куче новостных ресурсов и уже в печенках сидит. С другой, ваш пост легко пропустить и не обратить на него внимания. С третьей, а вдруг в ворохе ссылок кто-то найдет для себя что-то интересное?

Так что, если хотите, пишите и впредь — посмотрим, что из этого выйдет.
GUILLAUME LOVET — Гийом Ловэ с ударением на последние слоги
Аналоги вашего решения (не говорим ни про Backbone, ни про Knockout):

msdn.microsoft.com/en-us/scriptjunkie/hh297451
bruth.github.com/synapse/docs/

Также BB и KO — не единственные JS-MV*-библиотеки. Есть еще Ember, Batman, Spine, Knockback (BB+KO), SproutCore, JavaScript MVC и еще наверное с десяток.

Тем, кому хочется посмотреть на пример автора в деле: jsfiddle.net/Qvs3t/
Но в МакДак я вам ходить не советую. Иногда — можно, но не злоупотребляйте.
А скажите, зачем хранить профили 80 пользователей на сервере? Если это сервер компании, не хотел бы я там работать. Я считаю, что компании не стоить лазить ко мне в профиль.
Илья, а почему так долго? Разговоры о том, что Опера должна быть в AppWorld, шли еще с выхода Mini 5 — а это было аж весной 2010. Неужели так долго апрувили? :)
Opera в свое время проиграла десктопную гонку Firefox из-за того, что браузер был какое-то время платным, а потом в нем были баннеры — второй раз они такой ошибки не совершат. Рекламный сервис будет отдельным, а основным его козырем будет именно широкий охват платформ.

Вообще кроссплатформенность становится основным козырем Оперы: ни один другой браузер не обеспечивает таких ровных характеристик на столь разных платформах. Если вы тестируете на Mini, то ваш сайт будет работать вообще где угодно. А если вам хочется вовсю использовать HTML5, например, для веб-приложений корпоративного рынка, то можно предложить пользоваться Safari на iOS и Opera на остальных устройствах: а то стандартные браузеры что на Андроид, что на Симбиан, слабоваты в этом деле. У Opera Mobile и поддержка SVG, и теперь еще MediaCapture.

Мы теперь на нее равняемся в мобильных проектах. Времени на разработку уходит меньше, чем при использовании PhoneGap, а с точки зрения развертывания и в том, и в другом случае приходится с телефона лезть в маркет. В общем, ребятам и Opera я желаю всяческих успехов!
Ссылки на картографические сервисы на этот город: Google Maps, Yandex Maps, Bing Maps, OSM. желательно по два варианта: собственно ссылка и строка для эмбеддинга карты на страницу.

Статью в википедии уже назвали, какой-то дайджест о городе — по типу того, что попадает в ленту соц-сети, когда публикуешь ссылку.

Статистика тоже не помешала бы: например, я делаю запросы к вашему сервису, а вы мне данные о том, сколько посетителей пришло с каждого города, причем можно и в динамике. Графики аналитики тоже не помешали бы.
Да, особенно трудно сдержаться в первые месяцы жизни в Украине: практически все надписи и объявления кажутся смешными. Причем объяснить, почему украинский кажется смешным, никто вразумительно не может. И обижать тоже никого не хочется: язык красивый по звучанию и весьма богатый с точки зрения лексики, оборотов и эмоциональных средств. Потом привыкаешь и уже не можешь вспомнить, что именно казалось смешным.

Зато прекрасно отличаешь недавно приехавших россиян — они стоят в трамвае еле-еле сдерживают смех. Выглядит тоже весьма забавно и тоже вызывает улыбку. Так и живем: едем в трамвае и улыбаемся — новенькие нам, а мы им — а потом россияне приезжают домой и рассказывают всем, какие приветливые на самом деле люди эти украинцы :)

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Registered
Activity