Если представить наоборот, что один из таких аппаратов весом от 500 тонн летит к нам со скоростью 12% скорости света и врезается в центр (пусть океана), то становится интересно — какие нам ждать последствия?)
Ничего не имею против Android и даже рад ему, но почему даже на рекламном превью раздражающие подтормаживания? Когда же интерфейс станет плавным и в зависимости от мощности аппаратной части деградировать эффектами, но оставаясь производительным? Я очень хочу попробовать и CarPlay и AndroidAuto. Но если он будет таким, как показали, это будет резкий негативный параметр конкретной машины. Более того, субъективно даже машина будет казаться такой же по качеству, как качество этих эффектов, чистота шрифтов и качество элементов внутреннего интерфейса. Честно признаться, лучше стандартная магнитола с 1 цветом времени, названием радиостанции без навигатора, интернета и модных плюшек, но который не тормозит, чем подобное. А остальное по-старинке прикрепить рядом. Я даже уверенным не смогу быть, что в случае переключения радио и оно внезапно заорет громче моего комфортного порога смогу быстро и комфортно сделать потише в доли секунды, а не подожду парочку пока там анимация лесенкой прогрузится или сработает вызов с аппаратного контролла.
МИФ: электромобили оказывают чрезвычайно высокую нагрузку на электросети.
РЕАЛЬНОСТЬ: сеть спроектирована с расчетом на худшую секунду худшего дня худшего года — в них заложены избыточные мощности. Вы сможете заменить 70% пробега бензиновых авто пробегом электромобилей при использовании существующей сети. Этот процент еще вырастет с увеличением количества домохозяйств, имеющих солнечные батареи на своей крыше.
+ ко всему, зарядка электромобилей в подавляющем случае будет производиться ночью, когда среднее потребление в разы или даже на порядок меньше, чем пиковая дневная активность. Тем самым ночное потребление будет выравнивать график нагрузки, что только положительно сказывается на электрогенераторах.
Получил массу удовольствия от прочтения настолько детально разобранной статьи! Огромное спасибо автору и огромное спасибо за такой объемный перевод! Надеюсь, статей подобного охвата материала станет существенно больше.
Что касается темы статьи, то думаю, что электоромобили — одна из редких будущих отраслей, которая создает радостные мысли о будущем и перспективах. Не так много есть тем, по которым можно смело сказать, что нас ждет крайне интересное будущее.
Интересно, многим по прочтении первая мысль, приходящая на ум — попробовать использовать его как алертер статусных сообщений сервера? И далее дополнить возможностью управлять им простенькими командами?) Несколько раз устанавливал Телеграм, активно знакомился, щупал, изучал и постепенно он умирал из-за малой активности внутри. Теперь снова есть мотивация сделать это уже в n-ый раз -)
Хоть и очень далек от возможности привнести в код ядра Linux, но почитать было крайне интересно. Особенно понравилось, что вы поделились именно своим опытом (я про письмо разгневанного Линуса). На момент почувствовал, что это меня самого ругают -)
Я знал, что найти через меня ссылку на проект чрезвычайно просто. Таким образом заинтересованный человек получил бы нужное с минимумом движений, а вот все остальные мимо проходящие — поленились бы. Этим и объясняется мое желание умолчать о проекте. Спасибо, что отнеслись с уважением к моему желанию.
Статика на то и статика, что изменяется от случая к случаю. Поэтому если по очередном git status я вижу изменения в статичном файле, смотрю diff и комиччу его отдельно. Это редко и не вызывает проблем. По крайне мере если бы я был в настроении настраивать оптимизацию рабочих моментов, то начал бы далеко не с этого -)
Сейчас это никак не организовано, уж извините) Это просто пример того, что все таки не так сложно организовать деплой в автоматическом режиме. Части проекта, которые недоступны для пользователей — не вызовут аномальную нагрузку. Поэтому чаще всего достаточно просто вести разработку на какой-то скрытой части продакшена, лишь по готовности и утверждению активировав туда доступ. Все таки это самый быстрый режим работы и для него есть почти все инструменты (голова, бекапы, версионность) для нормальной работы без убийства всего остального.
Скрипт миграции не может быть универсальным. И даже если подумать о том, чтобы его сделать — он будет выполнять или слишком общие задачи, или его придется дорабатывать каждый раз под особую специфику. Поэтому я бы не стал его делать частью проекта и хранить в git. Лично я бы реализовал какой-то подобный патч скриптом на баше.
Очереди нет. Есть параллелизация. Три демона ждут обновление специальных ключей в мемкеше и по этому событию выполняют задачи, сохраняя/отправляя/передавая результат необходимым сервисам. В итоге все получатели получают информацию максимально быстро, в зависимости от сложности необходимых обработок. Реализовывать очередь — необходимо что-то вроде ноды, наверное. И вообще, всегда боюсь любых очередей, поэтому даже не старался исследовать этот вариант.
Ну статичный контент в файлах как раз очень хорошо поддается версионности. Проблема может возникнуть когда в статичном файле помимо include header и footer существует какой-то еще код. Тогда Битрикс его может «преобразовать».
А вот версионность базы — это беда. Для случая когда в php-коде встречается текст есть штатный функционал подключения языка, при применении которого даже в шаблоне нет ни единой фразы текста. То есть, с этим все ок, вроде, кроме версионности базы.
Что касается деплоя:
1) работаем на копии
2) утверждаем обновление
3) на продакшене запускаем скрипт миграции, который создаст/изменит инфоблоки и его свойства и далее забирает новые/измененные файлы с git. Опционально, подставляет значения ID созданных инфоблоков/свойств в параметры вызова нового функционала.
4) Готово
С тестами — пропасть. Множество файлов ядра имеет какие-то нетехнические комментарии, TO-DO и много просто закомментированных функций, которые были активны до обновления. (люблю иногда полистать git diff после обновления)
Вы правы. Использование Битрикса — сложилось исторически. Сначала студия, потом был программист, потом его сменил я. Но, к сожалению, я не могу сейчас ответить что бы я выбрал много лет назад, идеально зная то, что есть сейчас. Даже с нятяжкой не придумать того, что могло бы его заменить. Да и, может быть я бы вообще решил бы бросить веб-разработку, зная в ней предел стоимости работы и осознавая в чем порой приходится ковыряться. Вероятно, пошел бы учить что-то более низкоуровневое и более типизированное, объектное)
Касательно отдельного поста — думаю я часть большого количества людей, желающих идеалистично написать на хабр какой-то пост, но всегда терзают сомнения в полном разборе/понимании затрагиваемой темы. Поделиться есть много чем. Как идеями, так и чем-то законченным. Но всегда останавливают как причина выше, так и комплекс несостоятельности своей манеры передачи информации. Уж извините)
Все постепенно приходит к тому, чтобы использовать битрикс в режиме асинхронного хранилища контента, занимаясь кешированием и выборкой самостоятельно (своими средствами). Когда настанет момент, что есть лучшее хранилище самого разного контента и его выборки лучше чем битрикс (с точки зрения контент-менеджера прежде всего). Тогда мы сможем от него отказаться. А пока платим за две бизнес-лицензии, используя лишь админку и api.
Если подскажете выход или направление в какую сторону посмотреть — буду благодарен. Я — пока не нашел чего-то лучше.
На самом деле не жалко этих денег. Просто потому что я бы сам делал тот же самый функционал API и админки дольше. Если бы вообще смог повторить -). А требовать что-то еще — бессмысленно. Битрикс справится с любой задачей, которую он призван решить. Будто то интернет-магазин, блог, новостной портал. Причем не только функциональную задачу, но и задачу бизнеса. Проблемы начинаются тогда, когда: 1) не хватает штатного функционала — пишем свои решения; 2) нетипичная нагрузка — нельзя полагаться на массовое решение, когда твоя задача и решение специфично и единственна в своей реализации; 3) программирует битрикс начинающий разработчик — не по документации/правилам/паттернам/здравому смыслу. Во всех остальных типичных случаях он по моему мнению лучше других аналогов.
Проект действующий, многосторонний, рассчитанный на аудиторию в более 10 млн уников в месяц. Заказчик — мой работодатель) Это все, что я… хотел бы рассказать. Простите)
Архитектурно: CloudFlare (бизнес), nginx, php5-fpm, Percona, Ubuntu, munin на одном сервере 14 ядер по 2 ГГц, 32 Гб оперативки, 1 ТиБ место — хватает. Это веб-сервер. Другие серверы есть и похуже, что-то очень сильно получше — не имеют значения в обсуждении. Они больше заняты обработкой в live-режиме большого контента и раздачу большого контента. Веб-сервер с ними не взаимодействует, кроме статистики munin забрать, да пары мегабайт данных в 5 минут.
Модули с маркетплейса да — минимизация админки. К сожалению, у нас задачи вне рынка маркетплейса. Примеры таких задач: получать картинки с iTunes и Last.fm, взаимодействовать с сотовым оператором по поступающим смс (с программной логикой ответа — опционально), связь с каким-то оборуованием, отправляющим что-то на адрес в режиме raw, post, json — по-разному, банковский билинг (альфа, киви только сейчас), рассылки новостей (попробуйте сделать ее битриксом хотя бы на 10000 получателей), аплоад файлов весом по 200-400 Мб, массовый ресайз картинок в 4 формата, выдача json-ов для разных устройств от мобильных приложений, до медиацентров DuneHD, генерация rss. Все это нетиповые задачи, которых точно нет в маркетплейс, а что есть, с тем особо и не хочется разбираться и лучше сделать самому. Не сказал бы что это все какой-то космолет. Просто ставятся задачи и решаются. Битрикс хорош тем, что у него низкий уровень вхождения по изучению начинающим программистом. Решения в маркетплейсе расширяют штатный функционал или делают какую-то все таки типовую работу (чаще всего связанную с магазинами), которую проще купить, чем написать. У нас проще написать, ибо потом разбираться с чем-то не хочется. Плюс, покупая решение я боюсь в нем увидеть выкидыш зла, которое потом нельзя использовать. Кстати, забыл, есть одно установленное решение — интеграция со службой доставки СДЕК. Но его купили только потому что его стоимость была дешевле, чем чистое время писать интеграцию самим. Да и какой-то дальнейшей доработки функционала доставки не предусматривалось.
+ ко всему, зарядка электромобилей в подавляющем случае будет производиться ночью, когда среднее потребление в разы или даже на порядок меньше, чем пиковая дневная активность. Тем самым ночное потребление будет выравнивать график нагрузки, что только положительно сказывается на электрогенераторах.
Что касается темы статьи, то думаю, что электоромобили — одна из редких будущих отраслей, которая создает радостные мысли о будущем и перспективах. Не так много есть тем, по которым можно смело сказать, что нас ждет крайне интересное будущее.
upd.: почему-то ответ на подобный вопрос был в ветках ниже
и ссылка на blockchain.info
Скрипт миграции не может быть универсальным. И даже если подумать о том, чтобы его сделать — он будет выполнять или слишком общие задачи, или его придется дорабатывать каждый раз под особую специфику. Поэтому я бы не стал его делать частью проекта и хранить в git. Лично я бы реализовал какой-то подобный патч скриптом на баше.
А вот версионность базы — это беда. Для случая когда в php-коде встречается текст есть штатный функционал подключения языка, при применении которого даже в шаблоне нет ни единой фразы текста. То есть, с этим все ок, вроде, кроме версионности базы.
Что касается деплоя:
1) работаем на копии
2) утверждаем обновление
3) на продакшене запускаем скрипт миграции, который создаст/изменит инфоблоки и его свойства и далее забирает новые/измененные файлы с git. Опционально, подставляет значения ID созданных инфоблоков/свойств в параметры вызова нового функционала.
4) Готово
С тестами — пропасть. Множество файлов ядра имеет какие-то нетехнические комментарии, TO-DO и много просто закомментированных функций, которые были активны до обновления. (люблю иногда полистать git diff после обновления)
Если подскажете выход или направление в какую сторону посмотреть — буду благодарен. Я — пока не нашел чего-то лучше.
Архитектурно: CloudFlare (бизнес), nginx, php5-fpm, Percona, Ubuntu, munin на одном сервере 14 ядер по 2 ГГц, 32 Гб оперативки, 1 ТиБ место — хватает. Это веб-сервер. Другие серверы есть и похуже, что-то очень сильно получше — не имеют значения в обсуждении. Они больше заняты обработкой в live-режиме большого контента и раздачу большого контента. Веб-сервер с ними не взаимодействует, кроме статистики munin забрать, да пары мегабайт данных в 5 минут.
Модули с маркетплейса да — минимизация админки. К сожалению, у нас задачи вне рынка маркетплейса. Примеры таких задач: получать картинки с iTunes и Last.fm, взаимодействовать с сотовым оператором по поступающим смс (с программной логикой ответа — опционально), связь с каким-то оборуованием, отправляющим что-то на адрес в режиме raw, post, json — по-разному, банковский билинг (альфа, киви только сейчас), рассылки новостей (попробуйте сделать ее битриксом хотя бы на 10000 получателей), аплоад файлов весом по 200-400 Мб, массовый ресайз картинок в 4 формата, выдача json-ов для разных устройств от мобильных приложений, до медиацентров DuneHD, генерация rss. Все это нетиповые задачи, которых точно нет в маркетплейс, а что есть, с тем особо и не хочется разбираться и лучше сделать самому. Не сказал бы что это все какой-то космолет. Просто ставятся задачи и решаются. Битрикс хорош тем, что у него низкий уровень вхождения по изучению начинающим программистом. Решения в маркетплейсе расширяют штатный функционал или делают какую-то все таки типовую работу (чаще всего связанную с магазинами), которую проще купить, чем написать. У нас проще написать, ибо потом разбираться с чем-то не хочется. Плюс, покупая решение я боюсь в нем увидеть выкидыш зла, которое потом нельзя использовать. Кстати, забыл, есть одно установленное решение — интеграция со службой доставки СДЕК. Но его купили только потому что его стоимость была дешевле, чем чистое время писать интеграцию самим. Да и какой-то дальнейшей доработки функционала доставки не предусматривалось.