Зацепившись за вступление прочитал статью не отрываясь. Теперь знаю про термобарьеры, термопрофили и какие могут быть неочевидные косяки при проектировки платы. Только зачем мне это, если никогда не занимался разработкой железа? Автор молодец — умеет заинтересовать!
Скажу в защиту atlassian что тормозят в основном onDemand (облачные) версии их продуктов, в основном из-за больших пингов в сша…
Но примеры многих компаний, да и jetbrains в частности (они используют confluence) доказывает что jira работает весьма успешно, в том числе и из-за собственного железа.
Любой приложение не появляется из воздуха, а пишется планомерно. На одном из этапов и можно подключить модуль. Никто не говорит делать это каждый раз, когда нужно узнать про переменную.
Вы правы про production — там есть логи, но мы и говорим о разработке на локальной машине, нет?
И все равно, ничто не отменяет случай вывода нужной переменной/информации только для разработчика именно на рабочем сервере (именно вывода, никто не говорит про плохую привычку правок на лету)
да, вы правы — спрашивает, только закрывая окно (кнопка в заголовке, cmd-q — не спрашивает). А можно как то настроить поведение, чтобы и в этом случае не спрашивал?
Я использую sublime вместо блокнота для всевозможных заметок и для просмотра отдельных файлов из других не открытых проектов (в том же PhpStorm)… то есть как дополняющий инструмент =)
Sublime (под mac, не знаю как с win), при нештатном закрытии (рестарт системы, принудительное закрытие) нормально показывает несохраненные файлы, однако при обычном закрытие требует обязательного их сохранения. Есть ли плагин/настройка, которая позволит просто держать файл в редакторе без обязательного сохранения?
Как это не печально, космос развивался на энтузиазме отдельных людей, которые вложили в это свои жизни и тянули всю отрасль (они придумывали, находили финансирование теми или иными способами используя ситуацию), и лишь после этого началось сначало военное, а потом и коммерческое использование (спутники). Возможно сейчас именно этих первых шагов и не хватает, а коммерческое применение найдется уже позже…
Выделение текста в ссылка очень сильно раздражает с тех пор, как пересел на chrome. Немного спасает ситуацию расширение ToggleLink: Select Text From Link — нажатие shift, на наведенной ссылке временно убирает тег . Костыль и не всегда работает, но чаще всего спасает, В других случаях приходится выделять сопутствующий текст, копировать его куда-нибудь (в ту же адресную строку, и там выделять нужный кусок…
Быстрого отключения изображений так и не дождался, а вот повторная загрузка изображений решилась расширением Reload Image
Не хватает до сих пор быстрого перехода по элементам страницам с помощью горячих клавиш: если память не изменяет q, a для ссылок и w, s для заголовком, но могу ошибаться… Есть расширение Vimium, но все же не то…
И что, более интересно в браузере 10 летней давности можно было поменять любую горячую клавишу, любую менюшку! Было куча разных тем и оформлений: действительно разных по формам, иконкам, расположениями окон, а не просто другой картинкой на домашней странице!
Да стоит вопрос в целесообразности некоторых вещей..., но как небольшая команда разработчиков умудрялась вместить кучу разных вещей, утилит в 10-15 мегабайтный инсталятор, до сих вызывает восхищение!
Уже давно замечаю, что по субъективным ощущениям ваши карты в браузере на десктопе и планшетах работают заметно быстрее чем решения от яндекса или гугла, при куда большем количестве отображаемой информации. Особенно в случаях с плохим интернетом. Как вы этого добились?
В вполне распространенной ситуации, когда обзваниваешь много фирм в поисках чего-либо, сильно не хватает встроенных заметок — есть ли товар (простой чекбокс хотя бы) и по какой цене. Было бы удобно: обзвонил, фирмы без товара скрылись, оставшиеся отобразились списком или на карте…
1. Про html:
Я не отрицаю необходимость отделения кода от представления. О коде невозможно говорить в сферическом вакууме, и я скромно настаиваю лишь на адекватном отношении к каждой ситуации. Есть общие компоненты системы, которые почти не меняются от проекта к проекту: пользователи/rbac, а есть проектозависимые. И что в одной ситуации хорошо, то в другой будет плохо.
Задача: Есть в проекте модели, с парой полей, значения которых определяется константами нужно их отобразить значение и возможно оформление (иконка/текст).
Небольшие комментарии к модели
Я исхожу из того, что всегда надо сделать проще и понятнее:
Если константы, то значит выбор был небольшой и заранее известный, что не потребовало отдельного справочника
Поскольку полей мало, то это также не требует отдельной таблицы (скажем, id,modelName,key,value)
Мало/много — понятие относительное, надеюсь на вашу адекватную оценку, я отталкивался от границы около десятка-двух моделей.
Сложность логики отображения оцениваю в строках кода — больше нескольких строк, значит сложная. (об этом писал Макконелл)
Разберем разные ситуации:
моделей мало, полей мало, логика отображения сложная — используем виджеты, код разделяется
моделей мало, полей много, логика отображений простая — замечательно будет использовать класс хелпер, разные методы которого будут отображать разные вещи. При сложной логике используем, для отдельных элементов виджеты.
моделей много, полей мало, логика простая — если создавать для отображения каждого поля отдельный виджет и хелпер в котором будет один метод с объемом в пару строк, то вы просто потонете в файлах. Надеюсь не ошибусь, если припомню статью на хабре, где обсуждалась ситуация в Java, когда повсеместным стало подобное поведение — там все было разложено по полочкам. И да, для сложных ситуаций все равно используем виджеты.
И моя ошибка была в том, что я не указал, что у меня третий случай и в проекте весь интерфейс построен на бутстрапе, а значит ваш комментарий про css\js просто снимается (все уже включено)
2.
Чуть меньше не понравилась идея задавать символьные обозначения константам на естественном языке.
Вы говорили об массиве $statusTitles? Это не обозначения констант, а расшифровка из значений.
1. К константам в моделях я часто сразу добавляю их названия и геттер. Удобно тем, что можно и в виджетах (ListView\GridView) можно сразу прописать вывод статуса и в формах сразу передать список возможных значений в radio или select.
И не смотря на абсолютно правильную заметку об отделении html кода от логики, иногда отступаю от правила и добавляю метод, который выводит «разукрашенную» версию названия, поскольку добавление нового класса ради одного метода, считаю, внесет больше неудобства и путаницы.
/**
* @property string statusTitle
*/
class MyModel extend CActive Record{
const STATUS_CREATED = 1;
const STATUS_SENT = 2;
public static $statusTitles = array(
self::STATUS_CREATED => 'Новый',
self::STATUS_SENT => 'Отправленный',
);
public function getTypeTitle() {
return self::$statusTitles[$this->status];
}
public function getTypeTitleDesigned() {
return self::$statusTitles[$this->status];
}
/**
* для определенных случаев выводим "разукрашенную" версию статуса.
*/
public function getStatusTitleDesigned() {
// по своей логике определяем украшения: скажем, иконку и цвет в стиле Twitter Bootstrap'a
$color = 'success';
$icon = 'ok';
return TbHtml::labelTb(TbHtml::icon($icon) . " " . $this->statusTitle, array(
'color' => $color,
));
}
}
}
2. Связанные данные. (relations)
У CActiveRecord есть замечательная особенность — можно целиком переопределять свойство модели зарезервированное уже под связные данные в relations.
Если есть две модели Team и Member (думаю, связи и поля этих двух моделей очевидны) я использую этот прием для сохранения связанных табличных данных. В отличие от «официального» подхода здесь сохранение данных вынесено из контроллера в модель и можно работать с данными по имени связи сразу после их получения. Также становиться удобно одновременно сохранять данные родительской модели и связанных данных. (например, сразу создаем команду и заполняем информацию о ее участниках)
Код моделей и контроллера
/**
* @property Member[] $members
*/
class MyModel extend CActive Record{
public function rules() {
return array(
//....
array('newMembers', 'safe'), // для того чтобы можно было получить данные из формы
array('newMembers', 'validateData'), // для их валидации
//....
);
}
public function relations() {
return array(
//....
'members' => array(self::HAS_MANY, 'Member', 'teamId', 'index' => 'id'),
//....
);
}
/**
* Получение из формы табличных данных и объединение их с уже существующими.
* @param mixed $newMembers
*/
public function setNewMembers($newMembers) {
$members= $this->members;
foreach ($newMembers as $memberId=> $data) {
if (is_numeric($memberId) && $memberId!= 0) { // отсекаем ненужные данные
if ($members[$memberId]) { // если уже существует
$member= $members[$memberId];
} else { // если не находим, создаем новую модель
$member= new Member('create');
$member->teamId= $this->id;
$members[$memberId] = $member;
}
$member->team= $this; // для того чтобы избегать лишних запросов к базе
$member->attributes= $data;
};
}
$this->rates = $rates; // вся магия здесь =)
}
}
/**
* Проверка данных
*/
public function validateData() {
if (!$this->rates) return true;
$ok = true;
foreach ($this->rates as $rate) {
$ok = $rate->validate() && $ok;
}
return $ok;
}
/**
* Сохранение данных
*/
protected function afterSave() {
$this->saveData();
parent::afterSave();
}
public function saveData() {
if (!$this->members) return;
foreach ($this->members as $member) {
$member->save(false); // мы данные уже проверили в validateData()
}
}
Код контроллера получается логичным
class TeamController extends Controller{
/**
* Добавление нового команды и ее членов
*/
public function actionCreate() {
$model = new Team('create');
if (isset($_POST['Team'])) {
$model->attributes = $_POST['Team'];
$model->setNewMembers($_POST['Member']);
/*
Подразумевается, что в представлении в одной форме мы
вместе заполняем данные и для команды и для ее членов.
Хотя и здесь, конечно, можно выпендриться и добавлять все данные о членах команды
в том же массиве, что и команда.
Таким образом сократиться второе присваивание, только можно будет запутаться в именах. =)
*/
if ($model->save()){
Yii::app()->user->setFlash('success', 'Все замечательно');
$this->redirect(array('view', 'teamId' => $model->id));
}else{
Yii::app()->user->setFlash('alert', 'Возникли ошибки');
}
}
$this->render('create', array(
'model' => $model,
));
}
}
А где можно прочитать подробнее про сами сообщения для систем: в каком виде и какие данные получают трейдеры и их платформы? Ведь информация может быть крайне разнообразная — как удается формализовывать, по каким критериям?
Можете рассказать об экономической стороне вопроса: насколько снизились затраты на рабочее место: лицензии помимо Windows, тех. поддержка, время обслуживания?
Были ли какие-то кардинальные трудности или все шло примерно по плану?
Но примеры многих компаний, да и jetbrains в частности (они используют confluence) доказывает что jira работает весьма успешно, в том числе и из-за собственного железа.
Вы правы про production — там есть логи, но мы и говорим о разработке на локальной машине, нет?
И все равно, ничто не отменяет случай вывода нужной переменной/информации только для разработчика именно на рабочем сервере (именно вывода, никто не говорит про плохую привычку правок на лету)
Быстрого отключения изображений так и не дождался, а вот повторная загрузка изображений решилась расширением Reload Image
Не хватает до сих пор быстрого перехода по элементам страницам с помощью горячих клавиш: если память не изменяет q, a для ссылок и w, s для заголовком, но могу ошибаться… Есть расширение Vimium, но все же не то…
И что, более интересно в браузере 10 летней давности можно было поменять любую горячую клавишу, любую менюшку! Было куча разных тем и оформлений: действительно разных по формам, иконкам, расположениями окон, а не просто другой картинкой на домашней странице!
Да стоит вопрос в целесообразности некоторых вещей..., но как небольшая команда разработчиков умудрялась вместить кучу разных вещей, утилит в 10-15 мегабайтный инсталятор, до сих вызывает восхищение!
Я не отрицаю необходимость отделения кода от представления. О коде невозможно говорить в сферическом вакууме, и я скромно настаиваю лишь на адекватном отношении к каждой ситуации. Есть общие компоненты системы, которые почти не меняются от проекта к проекту: пользователи/rbac, а есть проектозависимые. И что в одной ситуации хорошо, то в другой будет плохо.
Задача: Есть в проекте модели, с парой полей, значения которых определяется константами нужно их отобразить значение и возможно оформление (иконка/текст).
Разберем разные ситуации:
И моя ошибка была в том, что я не указал, что у меня третий случай и в проекте весь интерфейс построен на бутстрапе, а значит ваш комментарий про css\js просто снимается (все уже включено)
2.
Вы говорили об массиве $statusTitles? Это не обозначения констант, а расшифровка из значений.
И не смотря на абсолютно правильную заметку об отделении html кода от логики, иногда отступаю от правила и добавляю метод, который выводит «разукрашенную» версию названия, поскольку добавление нового класса ради одного метода, считаю, внесет больше неудобства и путаницы.
2. Связанные данные. (relations)
У CActiveRecord есть замечательная особенность — можно целиком переопределять свойство модели зарезервированное уже под связные данные в relations.
Если есть две модели Team и Member (думаю, связи и поля этих двух моделей очевидны) я использую этот прием для сохранения связанных табличных данных. В отличие от «официального» подхода здесь сохранение данных вынесено из контроллера в модель и можно работать с данными по имени связи сразу после их получения. Также становиться удобно одновременно сохранять данные родительской модели и связанных данных. (например, сразу создаем команду и заполняем информацию о ее участниках)
Код контроллера получается логичным
Были ли какие-то кардинальные трудности или все шло примерно по плану?