В одной интернациональной компании, где я работал, было внутреннее правило, что все данные хранятся только на серверах в UK.
Частично из-за удобства администрирования, и частично — на случай внезапных проверок/маски-шоу/государственных переворотов в локальных офисах (которых было много по всему миру, в том числе в африканских странах).
Соответственно, московский офис работал по сути через remote desktop, что радости разработчикам не добавляло.
Видимо, гугл решил, что remote desktop это полумера и просто вывез персонал.
(точто так же как девелоперы и пишут новый код, и поддерживают существующий)
1) «Организовывать процессы» это основная задача, поэтому подзаголовки получились немного из разных логических уровней :)
Если, например, в компании нет бизнес-процесса «добавить новое портфолио», то может получиться так, что в одной системе это сделают, в другой забудут, а третья вообще будет не в курсе и поэтому упадет. Соотсветсвенно, чтобы система не падала, надо
а) Понять, насколько этот бизнес-процесс критичен, и можно ли обойтись ручным вмешательством каждый раз когда добавляется портфолио («Приоритизировать»)
б) Понять, что должно происходить в системе при добавлении портфолио ( «Определить scope», «Создавать артефакты для инженеров»)
в) Довести до всех, как всё будет\должно работать («Демонстрации, обучение и UAT»)
2) Подзаголовок «понимать трейдеров» (отвечать на вопросы про «длинную гамму на задней ноге» (с) скорее относится к «поддержке бизнес-процессов», понимание трейдеров и организация документации это уже способы достижения этой задачи
> Классы — это не всегда плохо. Необоснованная сложность — это плохо всегда.
Абсолютно согласен, осталось немного: понять когда сложность «необоснованная» :)
Класс вместо функции в учебном примере — необоснован.
Система плагинов вместо 3х строчек кода/простой фабрики — необоснована.
Классы Board/Cell в реальной библиотеке для игры «Жизнь» — мне кажутся обоснованными.
"… те сущности, которые являются объектами, лучше объектами и оставить. «Сделать HTTP запрос» это не объект, а вот Board и Cell вполне себе объекты. "
Если вы с этим не согласны, аргументируйте плиз. Заодно со ссылкой на «библиотеку гугла», где функциональность, эквивалентная классовым методам, вынесена в отдельные функции.
> Как он показал, все заделы под «понадобится» оказываются ненужными.
В оторванном от контекста примере — да. А если эта «жизнь» будет на самом деле библиотекой, которую будет использовать куча народа и каждый третий будет просить её немножко допилить? Про это ключевой разрабочик питона ничего не написал?
> Сделать в дальнейшем из функции класс не проблема :)
без изменения клиентского кода?
> Нужно просто понимать когда нужен класс, а когда функция.
это не так «просто», как показывает данный пример…
в пробном проекте для себя любимого, neighbors может быть и функцией, а вот если это долгий проект, требования могут меняться, етк, то лучше сразу сделать класс.
Это как раз и мастерство: знать, когда можно «срезать углы» и обойтись функцией, а когда надо и «соломки подстелить» и добавить возможность расширения…
Всё хорошо, но всё-таки те сущности, которые являются объектами, лучше объектами и оставить.
«Сделать HTTP запрос» это не объект, а вот Board и Cell вполне себе объекты. И по мере того, как они используются в программе, могут добавляться различные их разновидности (подклассы), и исходный класс может делегировать часть логики из методов neigbors/advance в подклассы прозрачно для пользователя…
Например, если нам надо поддерживать 2 вида клеток: 1) которые считают соседями клетки сверху-снизу; 2) которые считают соседями все клетки, включая диагонали.
С классом Cell метод neigbors переопределяется на раз без изменения API, с отдельным же методом neigbors надо менять API и способ вызова. А рефакторинг в большой системе на питоне еще то удовольствие…
Против такого хорошо помогает вежливое письмо в саппорт типа «Я попросил отписаться (в аттаче-подтверждение), в случае, если я продолжу получать Вашу рассылку, я напишу в соотсветсвующие органы и вашему домену капец».
*соответсвующие органы: spamcop.net spam.abuse.net, хостинг, провайдер, и т.д.
>Т.е. я не могу просто после резюме и кавер леттер в компанию
Можете, почему же. Как правило у всех компаниях на сайтах есть раздел contact us или непосредственно с вакансиями. HR, правда, может быть немногим лучшим агентов и работать по похожим принципам (чтение резюме по диагонали с целью поиска знакомых слов). Но есть одно существенное отличие: в отличие от агентов, которые заработают на Вас комиссию ( и следовательно заинтересованы, чтобы Вас взяли), HR на вас денюжку не заработает. Соотсветсвенно, хороший агент будет активно пинать и продвигать процесс, в случае же с HR'ом это придется делать самому.
> мне интересна конкретная компания, конкретная позиция
Это уже отличает Вас в лучшую сторону от 90% соискателей)
Очевидный недостаток — применимо только для методов, которые либо всегда возвращают None, либо всегда возвращают объект.
Метод типа такого оборачивать небезопасно:
def getChild(name):
return self.internalDict.get(name)
(да, можно спорить о том, что вместо None нужно вернуть null-object, но… все Non'ы замучаешься оборачивать)
Ну и в целом (имхо) недостаток метода в том, что он размывает границы между mutable и immutable объектами: читая код, неочевидно, вызываются ли все add,mul на одном объекте либо на цепочке созданных объектов.
Для похожего можно еще varargs использовать, здесь пример:
I posted a long opinionated rant tonight about how I think Google could be doing a much better job of thinking from the ground up in terms of services rather than products. Sadly, it was intended to be an internal post, visible to everybody at Google, but not externally. But as it was midnight and I am not what you might call an experienced Google+ user, by the time I figured out how to actually post something I had somehow switched accounts.
1. Суд запретил продажи планшетов Samsung за нарушение патента «А» Apple
2. Суд запретил продажи планшетов Apple за нарушение патента «B» Samsung
3. Суд запретил продажи всех планшетов, т.к. они так или иначе нарушают какие-нибудь патенты Apple и Samsung
4. Суд запретил продажи всего, что может иметь отношение к патентам
Давайте уж доведем ситауцию до абсурда — мы сейчас в районе пункта 1.5, немного осталось…
В одной интернациональной компании, где я работал, было внутреннее правило, что все данные хранятся только на серверах в UK.
Частично из-за удобства администрирования, и частично — на случай внезапных проверок/маски-шоу/государственных переворотов в локальных офисах (которых было много по всему миру, в том числе в африканских странах).
Соответственно, московский офис работал по сути через remote desktop, что радости разработчикам не добавляло.
Видимо, гугл решил, что remote desktop это полумера и просто вывез персонал.
1) организацию новых бизнес-процессов,
2) поддержку существующих бизнес-процессов.
(точто так же как девелоперы и пишут новый код, и поддерживают существующий)
1) «Организовывать процессы» это основная задача, поэтому подзаголовки получились немного из разных логических уровней :)
Если, например, в компании нет бизнес-процесса «добавить новое портфолио», то может получиться так, что в одной системе это сделают, в другой забудут, а третья вообще будет не в курсе и поэтому упадет. Соотсветсвенно, чтобы система не падала, надо
а) Понять, насколько этот бизнес-процесс критичен, и можно ли обойтись ручным вмешательством каждый раз когда добавляется портфолио («Приоритизировать»)
б) Понять, что должно происходить в системе при добавлении портфолио ( «Определить scope», «Создавать артефакты для инженеров»)
в) Довести до всех, как всё будет\должно работать («Демонстрации, обучение и UAT»)
2) Подзаголовок «понимать трейдеров» (отвечать на вопросы про «длинную гамму на задней ноге» (с) скорее относится к «поддержке бизнес-процессов», понимание трейдеров и организация документации это уже способы достижения этой задачи
www.androidzoom.com/android_games/casual/juggle-juggle_cfmod.html
На присоединённых территориях жизни видимо не было…
Абсолютно согласен, осталось немного: понять когда сложность «необоснованная» :)
Класс вместо функции в учебном примере — необоснован.
Система плагинов вместо 3х строчек кода/простой фабрики — необоснована.
Классы Board/Cell в реальной библиотеке для игры «Жизнь» — мне кажутся обоснованными.
Жду Ваших собственных аргументов и ссылки на «библиотеку гугла» с этим замечательным подходом…
"… те сущности, которые являются объектами, лучше объектами и оставить. «Сделать HTTP запрос» это не объект, а вот Board и Cell вполне себе объекты. "
Если вы с этим не согласны, аргументируйте плиз. Заодно со ссылкой на «библиотеку гугла», где функциональность, эквивалентная классовым методам, вынесена в отдельные функции.
В оторванном от контекста примере — да. А если эта «жизнь» будет на самом деле библиотекой, которую будет использовать куча народа и каждый третий будет просить её немножко допилить? Про это ключевой разрабочик питона ничего не написал?
без изменения клиентского кода?
> Нужно просто понимать когда нужен класс, а когда функция.
это не так «просто», как показывает данный пример…
в пробном проекте для себя любимого, neighbors может быть и функцией, а вот если это долгий проект, требования могут меняться, етк, то лучше сразу сделать класс.
Это как раз и мастерство: знать, когда можно «срезать углы» и обойтись функцией, а когда надо и «соломки подстелить» и добавить возможность расширения…
«Сделать HTTP запрос» это не объект, а вот Board и Cell вполне себе объекты. И по мере того, как они используются в программе, могут добавляться различные их разновидности (подклассы), и исходный класс может делегировать часть логики из методов neigbors/advance в подклассы прозрачно для пользователя…
Например, если нам надо поддерживать 2 вида клеток: 1) которые считают соседями клетки сверху-снизу; 2) которые считают соседями все клетки, включая диагонали.
С классом Cell метод neigbors переопределяется на раз без изменения API, с отдельным же методом neigbors надо менять API и способ вызова. А рефакторинг в большой системе на питоне еще то удовольствие…
*соответсвующие органы: spamcop.net spam.abuse.net, хостинг, провайдер, и т.д.
Можете, почему же. Как правило у всех компаниях на сайтах есть раздел contact us или непосредственно с вакансиями. HR, правда, может быть немногим лучшим агентов и работать по похожим принципам (чтение резюме по диагонали с целью поиска знакомых слов). Но есть одно существенное отличие: в отличие от агентов, которые заработают на Вас комиссию ( и следовательно заинтересованы, чтобы Вас взяли), HR на вас денюжку не заработает. Соотсветсвенно, хороший агент будет активно пинать и продвигать процесс, в случае же с HR'ом это придется делать самому.
> мне интересна конкретная компания, конкретная позиция
Это уже отличает Вас в лучшую сторону от 90% соискателей)
Метод типа такого оборачивать небезопасно:
def getChild(name):
return self.internalDict.get(name)
(да, можно спорить о том, что вместо None нужно вернуть null-object, но… все Non'ы замучаешься оборачивать)
Ну и в целом (имхо) недостаток метода в том, что он размывает границы между mutable и immutable объектами: читая код, неочевидно, вызываются ли все add,mul на одном объекте либо на цепочке созданных объектов.
Для похожего можно еще varargs использовать, здесь пример:
stackoverflow.com/questions/3883907/designing-an-python-api-fluent-interface-or-arguments
Вместо
vis = new pv.Panel().width(150).height(150);
использовать
vis = pv.Panel(width=150, height=150)
Например:
if ($condition) {
// Code here
} else {
// Code here
}
… превращается в:
perchance (£condition) {
// Code here
} otherwise {
// Code here
}
plus.google.com/110981030061712822816/posts/bwJ7kAELRnf
Hi external-world folks,
I posted a long opinionated rant tonight about how I think Google could be doing a much better job of thinking from the ground up in terms of services rather than products. Sadly, it was intended to be an internal post, visible to everybody at Google, but not externally. But as it was midnight and I am not what you might call an experienced Google+ user, by the time I figured out how to actually post something I had somehow switched accounts.
Но тем не менее очень познавательно
2. Суд запретил продажи планшетов Apple за нарушение патента «B» Samsung
3. Суд запретил продажи всех планшетов, т.к. они так или иначе нарушают какие-нибудь патенты Apple и Samsung
4. Суд запретил продажи всего, что может иметь отношение к патентам
Давайте уж доведем ситауцию до абсурда — мы сейчас в районе пункта 1.5, немного осталось…
0 %
Народ не мог понять, как какое-то число может равняться самому себе+1.