Мне из ТОП5 всего 1 идея там нравится. Я вот считаю бредом разделять звук для звонков и медиа. Если я убавил звук до 1, это значит я нахожусь там, где должно быть тихо.
Лучшее решение, конечно это сделать регулировку опциональной, но и сейчас это не то что нужно реализовывать.
А между тем экран всех уведомлений, там не на 1 месте. А VPN ещё ниже.
Прелесть синтаксиса Python в том, что он заставляет разработчика придерживаться хоть какой то части code style, вне зависимости от его желания.
Так что, открывая чужой Python код, вероятность, что тебе не станет плохо — больше :)
И вечная головная боль — автоподгрузка скриптов (или не автоподгрузка, если идеология не позволяет)
На столько большая, что в каждом фреймворке свой костыль.
И и и и… и ещё 1000 и.
Единственное преимущество PHP перед Python — это быстро сделать небольшой веб-проект на Yii (1.5 года работал с Sf2 и немного со множеством других фреймворков и только Yii дает простоту и скорость разработки). В Python, увы по сложнее с быстротой разработки небольшого проекта.
Есть одна проблема в текущем техническом образовании. Мало акцентируют у студентов внимание на термины. Читая статьи и комментарии, можно наткнуться на то, что большое количество хаброюзеров использует термины абсолютно не вдумываясь в их значение. «Принцип» вместо «способ» или «архитектура» вместо «структура» — легко и просто. А без этой основы, правильно понять ГОСТ, на мой взгляд — невозможно.
Поэтому, сколько бы вы ни писали про ГОСТ, многие вас, просто, не поймут.
Скажем так, нет дешевой целостности, которую можно достичь с помощью 3-тей простой формы представления данных (join в BD) Если нет средств на команду, то убивать кучу времени на создание надстройки для создания целостности информации — совсем плохое решение.
Опять же, если задача не требует (например, хранение лишь авторизационных данных пользователей мобильного приложения) то AppEngine подходит. Но таких задач не много, что подтверждается самим Google и их «историями успеха».
| Если стоят задачи масштабирования
Масштабирование не отменяет задачи целостности. Для масштабирование можно строить для клиента отдельные поисковые индексы(срезы), с разным периодом актуальности.
Все истории успеха платформы AppEngine, который показывает Google — это самые простые задачи, аля авторизация для мобильного клиента (Angry Birds)
Морфологического поиска точно нет. На счёт полнотекстового, не так давно, там тоже засада была. Поменяли они всю документацию, не могу ограничения найти быстро.
Ну и оперативку AppEngin есть слишком много, вообще не адекватно дорого выходит.
В примере из статьи тоже нужно оборачивать.
А вот данный пример мне больше нравится, только нужно посмотреть что там будет с трейсом, не сломается ли он от этого.
Вы простите, но данный пример это не читабельный код.
Прерывать выполнение одной здоровой функции, а потом ещё switch со здоровыми телами.
Затем взявшийся из внешней области видимости res.
Вас, кстати не смущает, что вы несколько раз в одном блоке объявляете одну и те же переменные?
В России и не будут платить за тот контент, который интересен Японцам.
Например смайлик нас как правило не сильно интересует. И уж точно из-за него на мессенджер новый переходить не будут.
Orm::getModel
это паттерн фабричного метода. нарушение одного из принципов SOLID — конкретно того, что спрятан за буквой S
Можете расписать почему, я например, не понимаю :(
Лучшее решение, конечно это сделать регулировку опциональной, но и сейчас это не то что нужно реализовывать.
А между тем экран всех уведомлений, там не на 1 месте. А VPN ещё ниже.
Так что, открывая чужой Python код, вероятность, что тебе не станет плохо — больше :)
На столько большая, что в каждом фреймворке свой костыль.
И и и и… и ещё 1000 и.
Единственное преимущество PHP перед Python — это быстро сделать небольшой веб-проект на Yii (1.5 года работал с Sf2 и немного со множеством других фреймворков и только Yii дает простоту и скорость разработки). В Python, увы по сложнее с быстротой разработки небольшого проекта.
Поэтому, сколько бы вы ни писали про ГОСТ, многие вас, просто, не поймут.
Опять же, если задача не требует (например, хранение лишь авторизационных данных пользователей мобильного приложения) то AppEngine подходит. Но таких задач не много, что подтверждается самим Google и их «историями успеха».
Масштабирование не отменяет задачи целостности. Для масштабирование можно строить для клиента отдельные поисковые индексы(срезы), с разным периодом актуальности.
Все истории успеха платформы AppEngine, который показывает Google — это самые простые задачи, аля авторизация для мобильного клиента (Angry Birds)
Морфологического поиска точно нет. На счёт полнотекстового, не так давно, там тоже засада была. Поменяли они всю документацию, не могу ограничения найти быстро.
Ну и оперативку AppEngin есть слишком много, вообще не адекватно дорого выходит.
Нет ни join, ни какого либо приличного поиска.
Авторизацию для мобильного приложения на нём делать?
А вот данный пример мне больше нравится, только нужно посмотреть что там будет с трейсом, не сломается ли он от этого.
Прерывать выполнение одной здоровой функции, а потом ещё switch со здоровыми телами.
Затем взявшийся из внешней области видимости res.
Вас, кстати не смущает, что вы несколько раз в одном блоке объявляете одну и те же переменные?
var url =…
var data =…
var url =…
var data =…
var res2 = yield _get(«test2.txt», resume());
Например смайлик нас как правило не сильно интересует. И уж точно из-за него на мессенджер новый переходить не будут.