Я бы не хотел, чтобы дверь моей машины мог открыть любой, если я стою рядом, и наоборот, мне бы хотелось с расстояния открыть дверь машины, если моему знакомому из нее что-то нужно забрать. Пока не появится искусственный интеллект, способный сам правильно определить, можно открывать человеку дверь или нельзя, механическая кнопка будет наиболее надежным и удобным интерфейсом.
Основная проблема открывания двери ключом — это необходимость в наличии ключа. Именно поэтому постепенно отпадают плееры, фотоаппараты и другая техника. Все с собой не потаскаешь. Мне кажется, идеальным вариантом был бы носимый гаджет (часы) с несколькими настраиваемыми кнопками. У каждого человека свой набор необходимых действий, и каждый может настроить такой гаджет под самые частые свои действия, как в программируемых кнопках на клаве компьютера.
А мобильное приложение, приведенное в пример в статье — конечно верх идиотизма. Я бы добавил виджет на рабочий стол для такой популярной функции, или придумал что-то подобное. Ну и да, на рабочем столе моего смартфона не сотни иконок, а только пара десятков самых юзабельных.
Для сокращения размеров атласа/количества файлов неплохой идеей было б нарисовать отдельно стрелку и отдельно отдельно отблеск.
Собственно, в Юнити так и сделано в компоненте кнопки: есть компонент-контейнер с фоном, и внутри него компонент-содержимое. В дефолтной кнопке в Юнити содержимое — это компонент-текст, но его можно легко поменять на что угодно.
Перемещаете курсор на запятую, нажимаете alt+enter или появившуюся лампочку, выбираете «Inspection options->edit inspection profile setting», убираете ненужную галочку. По крайней мере так в PhpStorm 7
Хотелось бы нативного решения. С расширениями всегда проблемы, особенно когда их много. Я чтобы лису довести до нужного мне состояния, установил несколько расширений на вкладки. В итоге получались невеселые баги.
Наткнулся на баг в боковой панели закладок:
— нажимаю плюс для добавления новой закладки;
— вбиваю адрес закладки;
— удаляю то, что автоматически подставилось в заголовок;
— Вбиваю заголовок закладки. Если вбивать заголовок достаточно быстро, то при попытке ввести пробел, пробел сначала введется, а потом удалится, и получается, что все слова написались слитно. Если печатать медленно, то все ок. Причем баг появляется только если в адресе уже что-то вбито.
И еще вопрос: не могу найти настройку «Открывать новую вкладку рядом с текущей». Она планируется?
Это работает в большинстве случаев, но не всегда. Я могу получить groupId из надежного источника, например если мне нужно скопировать запись в БД. При хорошем lazy load у меня будет groupId, но не будет самого group.
Конечно, направлять разработчика на best practies — это хорошо. Но если программист неопытен, или если он просто идиот, то он будет ставить конкретные костыли, и будет еще хуже. Если же программист грамотный, то он хорошо знает, когда можно и нужно поступиться best practies, а система не позволит ему это сделать, и хороший программист будет грустить. И я говорю сейчас не только об этом конкретном примере, который мы обсуждаем, но обо всей симфони, и доктрине в частности.
Сам далеко не фанат доктрины, но со многим в статье не согласен. Например lazy load штука хорошая, но плохо контролируется в доктрине.
Главными недостатками доктрины вижу чрезмерную монструозность и тормознутость, сложность реализации простых вещей, и неочевидность поведения в сложных случаях.
Примеры:
— найти все записи, у которых значения поля больше определенного значения. Все, прощайте простенькие методы репы, здравствуй QueryBuilder;
— от getScalarResult() я ожидал массив вида: [1,2,3], а получил [0=>[1], 1=>[2], 2=>[3]]. Результат совершенно не отличается от getArrayResult();
— простой, быстрый и элегантный запрос с подзапросом в джойне невозможно реализовать в DQL, а с подзапросом в where мне не подходил. Пришлось делать два запроса;
— еще несколько примеров, которые я не могу привести в силу сложности условий для возникновения;
Я уж не говорю про костыли при работе с плохо спроектированной БД — тут вообще ад и извращения.
Не принципиально. Я открою несколько сайтов химчисток, чтобы сравнить их. Если информации на сайте для меня недостаточно, я его закрываю. Если достаточно — могу скинуть ссылку на прайс кому-нибудь: «Вот, смотри, тут дешевле». Не буду же я общаться с несколькими компаниями по телефону, чтобы узнать, какая химчистка мне подходит больше, это займет кучу времени. А еще по телефону мне будут впаривать всякую хрень, а я этого не люблю.
Если бы вы использовали голый язык, то с такой проблемой столкнуться не пришлось бы. Язык он и есть язык и новому разработчику в команде не пришлось бы тратить столько времени на понимание фреймворка, он бы сразу смог работать.
Только вот в любом сколько-нибудь сложном проекте всегда будет какая-то структура, классы, интерфейсы, функции, и пришлось бы тратить время на понимание всего этого, скорее всего без толковой документации. А фреймворки мало того, что имеют документацию, так еще обычно и довольно хорошо спроектированы, имеют большой функционал, и вероятность того, что попадешь в команду, использующую изученный тобой фреймворк, не так уж и мала.
да, я действительно ошибался, но не так уж и сильно. Родительское private свойство можно переопределить в потомке как public. Иначе получается, такой код не может иметь право на существование (пример на шарпах, но в плюсах поведение такое же):
class Foo
{
private int one;
public int two;
public Foo(){}
};
class Bar : Foo
{
public int one;
public Bar(){}
};
В php поведение точно такое же, public свойство создается в дочернем классе поверх private свойства в родительском, только в php это происходит на лету, во время исполнения, в то время, как в плюсах это нужно указывать явно.
Свойство класса, к которому нельзя обратиться даже внутри самого класса само по себе бессмысленно, поэтому его наследование так же имеет мало смысла. Но, кстати говоря, то, что в php дочерний класс не наследует private свойства родительского класса не совсем верно. Это можно показать на таком примере:
<?php
class Foo
{
private $one = 1;
public function getOne()
{
return $this->one;
}
}
class Bar extends Foo
{
public $one = 2;
}
$bar = new Bar();
echo $bar->getOne(); // выведет 1
Результат аналогичного кода идентичен в C#. Родительское свойство есть в дочернем классе, но доступно оно только в методе, унаследованном от родительского класса (все верно, зачем нужно свойство, которое никак нельзя использовать).
Вот и получается, что поведение в php не отличается от поведения в c++. Отличие только в формулировке текста ошибки и в том, что переменные (и свойства класса) в php можно использовать без явного их объявления.
Да, я ошибся, в с++ действительно private свойства наследуются. Сбила с толку статья, где было описано, как наследуются public и protected свойства при public, protected и private наследовании, но не было сказано про наследование private свойств.
Все правильно, такова особенность PHP — создание свойств на лету. Товарищ dnovikoff предъявляет претензию, что php неправильно интерпретирует модификатор private, но это не правда.
Для того чтобы выжить необязательно спускаться на поверхность планеты
На поверхности колония протянет вообще пару суток, не больше.
достаточно находится на высоте с приемлемой температурой и давлением.
Для начала в этом мало смысла, не намного больше, чем организовать колонию на орбите Венеры. Во-вторых, содержать в приемлемом состоянии воздухоплавательную колонию в разы сложнее, чем наземную, особенно во враждебной среде.
О чем вы говорите, если Солнца не везде хватает даже на Земле, а она гораздо ближе к нему, чем Марс.
Где солнца не хватает? В Питере? Так и на Марсе особо-то облаков нет.
А мобильное приложение, приведенное в пример в статье — конечно верх идиотизма. Я бы добавил виджет на рабочий стол для такой популярной функции, или придумал что-то подобное. Ну и да, на рабочем столе моего смартфона не сотни иконок, а только пара десятков самых юзабельных.
Собственно, в Юнити так и сделано в компоненте кнопки: есть компонент-контейнер с фоном, и внутри него компонент-содержимое. В дефолтной кнопке в Юнити содержимое — это компонент-текст, но его можно легко поменять на что угодно.
— нажимаю плюс для добавления новой закладки;
— вбиваю адрес закладки;
— удаляю то, что автоматически подставилось в заголовок;
— Вбиваю заголовок закладки. Если вбивать заголовок достаточно быстро, то при попытке ввести пробел, пробел сначала введется, а потом удалится, и получается, что все слова написались слитно. Если печатать медленно, то все ок. Причем баг появляется только если в адресе уже что-то вбито.
И еще вопрос: не могу найти настройку «Открывать новую вкладку рядом с текущей». Она планируется?
Конечно, направлять разработчика на best practies — это хорошо. Но если программист неопытен, или если он просто идиот, то он будет ставить конкретные костыли, и будет еще хуже. Если же программист грамотный, то он хорошо знает, когда можно и нужно поступиться best practies, а система не позволит ему это сделать, и хороший программист будет грустить. И я говорю сейчас не только об этом конкретном примере, который мы обсуждаем, но обо всей симфони, и доктрине в частности.
Не знаю, как у вас все работает, но
не работает, если у User есть ManyToOne user.group. Доктрина видит, что group у user не установлен, и затирает groupId
Это точно не умеет. Очень неудобно конечно, приходится извращаться, что портит и код, и производительность.
Немного не понял, о чем вы. Можете пример привести?
Главными недостатками доктрины вижу чрезмерную монструозность и тормознутость, сложность реализации простых вещей, и неочевидность поведения в сложных случаях.
Примеры:
— найти все записи, у которых значения поля больше определенного значения. Все, прощайте простенькие методы репы, здравствуй QueryBuilder;
— от getScalarResult() я ожидал массив вида: [1,2,3], а получил [0=>[1], 1=>[2], 2=>[3]]. Результат совершенно не отличается от getArrayResult();
— простой, быстрый и элегантный запрос с подзапросом в джойне невозможно реализовать в DQL, а с подзапросом в where мне не подходил. Пришлось делать два запроса;
— еще несколько примеров, которые я не могу привести в силу сложности условий для возникновения;
Я уж не говорю про костыли при работе с плохо спроектированной БД — тут вообще ад и извращения.
Только вот в любом сколько-нибудь сложном проекте всегда будет какая-то структура, классы, интерфейсы, функции, и пришлось бы тратить время на понимание всего этого, скорее всего без толковой документации. А фреймворки мало того, что имеют документацию, так еще обычно и довольно хорошо спроектированы, имеют большой функционал, и вероятность того, что попадешь в команду, использующую изученный тобой фреймворк, не так уж и мала.
В php поведение точно такое же, public свойство создается в дочернем классе поверх private свойства в родительском, только в php это происходит на лету, во время исполнения, в то время, как в плюсах это нужно указывать явно.
Свойство класса, к которому нельзя обратиться даже внутри самого класса само по себе бессмысленно, поэтому его наследование так же имеет мало смысла. Но, кстати говоря, то, что в php дочерний класс не наследует private свойства родительского класса не совсем верно. Это можно показать на таком примере:
Результат аналогичного кода идентичен в C#. Родительское свойство есть в дочернем классе, но доступно оно только в методе, унаследованном от родительского класса (все верно, зачем нужно свойство, которое никак нельзя использовать).
Вот и получается, что поведение в php не отличается от поведения в c++. Отличие только в формулировке текста ошибки и в том, что переменные (и свойства класса) в php можно использовать без явного их объявления.
На поверхности колония протянет вообще пару суток, не больше.
Для начала в этом мало смысла, не намного больше, чем организовать колонию на орбите Венеры. Во-вторых, содержать в приемлемом состоянии воздухоплавательную колонию в разы сложнее, чем наземную, особенно во враждебной среде.
Где солнца не хватает? В Питере? Так и на Марсе особо-то облаков нет.
Ядерная реакция, биотопливо, геотермальные источники, ветряная энергетика.
Для восполнения энергии, кроме Солнца (которого не так уж и мало на Марсе), есть куча других источников.