Мне кажется, что сперва нужно определиться с целями изучения языка. Если хотите получить хорошие академические знания, приближенные к проф. переводчикам, то имхо без педагога и уймы потраченного времени на зубрежку и другие страдания здесь никак.
Но подобный уровень знаний вряд ли реально нужен, большинству требуется выучить бытовой язык, чтоб можно было читать и общаться без словаря на общие темы. В этом случае можно «схитрить» и подучить язык за довольно сжатый срок.
Сразу скажу, что я не педагог и ни на что не претендую. Проанализировав проблему изучения английского в России я выявил, что одна из основных проблем — обучение академическому английскому + очень мало практики. В итоге, школьник или студент может прекрасно знать грамматику, структуры языка и пр., но попроси его пообщаться с иностранцем, и у него ничего не выйдет.
На данный момент я достаточно свободно пишу, читаю, говорю, смотрю сериалы и тп на английском (естественно, без словарей) и начинаю учить испанский.
Для себя я решил, что у меня нет времени на долгое изучение, меня может попросту не хватить на это, я хочу добиться быстро первых результатов и надеюсь, что эффект результата будет служить стимулом двигаться дальше. Идти к педагогам или на курсы не хочу принципиально, хочу проверить смогу ли я это сделать сам :)
Я считаю, что для этого надо максимально быстро перейти к практике, общение по скайпу с носителями. Для это надо овладеть самыми основами.
Вообще, все изучения я планирую построить рекурсивно: изучая минимум чего-либо за короткий срок (1-2 мес), практика, оттачиваю нюансы, изучаю что-то более сложное и так далее.
Первая проблема с которой пришлось столкнуться — это слишком богатый грамматический мир испанского языка. Очевидно, что в реальности используется намного меньше грамматических структур. Я попытался определить, что из этого мне надо знать в первую очередь, но не смог :) Я общался с испанцами и мексиканцами, но почему-то никто не смогу мне внятно объяснить структуру основных времен. В итоге я нашел примерно то, что мне надо в каком-то учебнике по языку.
Так вот, первая стадия само-обучения: зазубрить минилекс (400 ходовых слов) и очень базовую грамматику в срок 1-2 месяц. Это должно дать возможно хоть как-то начать общение.
Вторая стадия: найти носителей и начать общаться с ними по скайпу. (найти таких можно на сайте кочсерферов)
Третья стадия определится в ретроспективе первой и второй…
Для зубрежки минилекса планирую испытать разные методики — карточки, стикеры на предметы, зубрежка в через определенные интервалы времени и перед сном, а так же карточки без русского перевода, но с картинками предметов.
Еще во времена изучения английского случайно родилась следующая методика: когда я куда-либо шел я придумывал какую-нибудь тему и на английском сам себе рассказывал. В итоге в каких-то местах я понимал, что не знаю как это сказать, приходил домой и смотрел в словаре и переводчике.
Мне кажется очень важным заучивать слова и привязывать их не к переводу, а к образу, я думаю, это должно отчасти решить проблему внутреннего перевода (т.е. говорить то, что вы хотите сказать сразу на нужном языке, а не сначала про себя подумать на русском, вспомнить все правила и тп и родить перевод).
Если все это сработает, то возможно к осени я уже хоть как-то, но смогу вести беседу на испанском. А если нет, то вряд ли смогу когда-либо осилить еще один язык :))
Нет, совсем от ИБ мы не отказывались. В нашем случае ИБ это как бы база данных. Поэтому все родное (админка и другие модули) работают нормально, без изменений.
ИБ структуру так же нигде для этих целей не дублировали (кроме как в монго для кеширования и поиска). Поиск по API битры возвращает только ID'шники, а потом по ним из монго тянется весь объект. Где удобнее — ищем в монге. Тут суть в том, что битрикс делает доп. запросы, чтоб собраться все свойства элемента и сами запросы могут быть сложные за счет пачки join'ов. В монго же хранится «плоская» структура, т.е. объект сразу со всеми свойствами.
Когда администраторы системы меняют что-то в админке, то после сохранения срабатывает битровый хук и данные обновляются в монго.
К сожалению выложить в паблик не могу.
Вообще, архитектурно ничего сверхъестественного нету, решения вполне стандартные и описанные в любом источнике по DDD.
Изначально у нас был вариант а-ля Active Records, был базовый класс сущности, который мог сохранять элемент в ИБ, от этого класса наследовались другие сущностные классы. Все свойства у классов были описаны в phpdoc нотациях, поэтому в модулях и компонентах оперировали только объектами, с нормальной поддержкой от IDE.
Но при росте сложности AR модель начинает показывать свои недостатки, вот, и поэтому переписали работу с ИБ.
Мепперы — это прослойка, которая берет сущностные классы или контексты данных и сохраняет в БД. В этом случае получается бизнес уровень полностью независимый от субд и прочего. Это дает довольно хорошие бонусы, по сути, мы можем нашу логику перенести под что угодно, например, переписать все под symfony (ну а мы, например, сделали свои high load iblock, не дождались так сказать :)). Ну, а недостаток, как я уже написал — это увеличение по сути бесполезного кода в мепперах.
Вопрос, тут на самом деле в другом, на какой черт надо городить все это в битре, потому что для сайта визитки или типового магазина данный функционал будет больше вредить. А на проектах, где реально начинают проявляться бонусы DDD, использовать битру как минимум сомнительно.
Мы тоже написали свою ORM для битрикса, но немного в не в таком ключе как у вас. Наши сущностные классы не привязаны напрямую к api битрикса, а работа с api идет через мепперы.
Таким образом, мы легко можем и юнит тесты писать, да и вообще делать много интересных штук (например, дублирование и синхронизацию данных ИБ в mongodb, и поиск на фронте делать по монге, что дает существенные бонусы, а если еще взять и работу с геоданными, то восторг программистов не описать словами :) )
Из минусов — естественный оверхед в dto и т.п. Но на больших проектах преимущества побеждают геморрои :)
Алгоритмика — это знания различным известных алгоритмов, плюс сообразительность, там где эти знания кончаются.
Мне кажется алгоритмика, в отличие от сообразительности, штука прокачиваемая: чем больше знаешь классических алгоритмов, связанных с ними структур данных, тем проще решить те или иные алгоритмические задачи. Это как слух развивать.
А вот сообразительность, она, как мне кажется, либо есть, либо увы нет.
С опытом проведения собеседований пришла гипотеза о том, что умный, талантливый человек — талантлив во многих областях. Поэтому чтобы определить врожденные умственные навыки можно попробовать поговорить с человеком на абсолютно разные темы, никак не связанные с ИТ или конкретной вакансией. Например, спросить что кандидат думает о текущем положении в стране, или как накормить голодающие населения Африки — рвите шаблоны, программист это не робот для кодирования, это человек, с ним можно и нужно общаться на разные темы :)
Я проводил довольно много собеседований на вакансию программиста в нашем небольшом городе. Не могу судить о крупных городах, но проблема провинциального хедхантеринга, по моему опыту заключается в том, что шанс найти специалиста подходящего вам априори крайне, крайне мал.
Адекватные опытные спецы давно свалили в мск/спб или работают удаленно, их рейты скорее всего выросли настолько, что уже стали больше рейтов вашей компании.
Неадекватные опытные спецы, гики и прочие, за счет своей врожденной социопатии и неумения общаться с людьми вполне могут застрять навечно в провинции. Они даже могут прийти на собеседование, но в коллективе, к сожалению, такие люди приживаются плохо, их кругозор зациклен только на технической части и не обращает внимания на другие бизнес требования, заставить что-либо их делать против их мировоззрения сложно, а если за ними пристально не следить, то вместо простого решения, вы получите космический корабль, на неизвестных технологиях. Это супер круто с технической части, но как вам с этим жить дальше?
Третий вид кандидатов — это «вчерашние» студенты. Собеседовать их — одно удовольствие. Т.е. это как анекдот, мы даже иногда зовем их на собеседование в пятницу вечером, чтоб расслабить коллектив чуточкой фана, что конечно, довольно цинично. Провинциальные вузы не учат ничему, только завышают ЧСВ — студент прослушал лекцию дотнета и считает, что он отлично знает, к примеру, сиш. Так и говорит: «Я считаю, я хорошо знаю c#». На деле же, почти никто не смог назвать ни одного паттерна.
Что такое синглтон? — мммм, не сталкивался.
Ладно, ок, Вы использовали интерфейсы? — что простите?
Интерфейсы… — ммм,
Ну, вы знаете, что такое интерфейс в c# — мммм, не сталкивался.
Даже не пытайтесь спрашивать, что либо сложное. Хотя, если только по вечерам пятницы. Надо следующих просить попкорн захватить.
Так вот, суть в сухом остатке в том, что в провинции ваше собеседование направлено не на поиск специалиста, а на поиск не совсем испорченного вчерашнего студента, которого хардкорными, унизительными вопросами приводишь к тому, что он осознает свой уровень, и если повезет, через несколько месяцев активного вправления мозга, он начинает что-то собой представлять. А еще через пару месяцев он успешно проходит собеседование в мск/спб и валит туда. Утрирую конечно, но схема очень жизненна.
Если говорить о собеседовании, то оно меняет свой формат, на технические вопросы адекватного ответа не получить, приходится придумывать, «разбалтывать» человека, что б понять его суть, что он делал, какие планы на жизнь, чем увлекается. Можно спросить про математику, но тут все настолько уныло, что даже не смешно. Такие вопросы сразу выявят сбившего с пути молодого гика, готового к перевоспитанию, а если вас угораздило делать ИТ бизнес в провинции — это без сомнений ваш вариант
1. Мне кажется пример проблемы с orm довольно очевиден, возможно вы не так поняли, что я пытался сказать в посте. Ок, внешняя связь — в общем случае, это абстракция связи между двумя сущностями. В контексте рел. субд это например внешние ключи. Большинство современных ORM отлично обрабатывают внешние ключи и переносят абстракцию в сгенерированные сущностные классы, поэтому пример проблемы на самом деле больше надуман, чтоб показать суть. Если более конкретно, то например, из моделей сгенерированных через linq2sql ( sqlmetal ) нельзя получить контекст, и, если представить, что sqlmetal не умел бы обрабатывать внешние ключи (или ключа бы просто не было), то вместо такого «order.Products» вообще у сущности ордера ничего не было б, поэтому из сущностного класса получить сведение о связанных продуктах не получилось б.
2. Естественно это не ddd. Как бы об этом потом и говорится.
Интересно было б услышать Ваш вариант реализации описанной задачи в методологии DDD
без обид, но по-моему вы не внимательно прочитал пост и комментарии, и про моделирование домена через схему бд и про то, что DDD и DbDDD к ООП не имеет отношения (в теории) про все это тут уже написано
Мне кажется подобные попытки создать демо-модель на «людях-транспортах» несколько неудачны по той причине, что они слишком абстрактны и вырваны из контекста.
В реальной ситуации у вас будет еще масса условий, в том числе и не связанных с программированием. И мой подход — это комплексный анализ всех условий.
Ведь в ddd есть еще такие понятия как value-object и aggregate model. Может быть у вас «человек» это value-object? А может и нет. Может быть у вас автобус это aggregate model и содержит человека как часть себя?
Ну так вы спросите Noofiz почему он так считает.
Статья — не пересказ книжки, статья — пересказ моего осмысления пачки книжек, гуглинга темы, практического опыта. Как-то так.
нет, не смущает
потому что data driven (или data centric) встречается у других довольно, на мой взгляд, авторитетных гайдлайнах о разработке (например, в гайдлайнах от майкрософта, у них вообще прямое противопоставление идет, мол если у вас приложение простецкое возможно вам стоит обратить внимание на Data Driven)
К сожалению, реального практического опыта с OODMS пока нет. Из нереляционных СУБД мы используем MongoDb (с .net'ом потому что у него есть linq адаптер, и как показала практика переехать с mssql на mongo вышло не так уж и сложно, за счет абстракций уровня данных, но тем не менее основной субд является mssql по ряду других практических причин). Раньше использовали CouchBase (в основном в связке с проектами где много javascript'а).
Вот, и хотя Mongo не является OODMS, но она позволяет сохранять скимлесс-документы и, да, это порой может реально упростить меппинг моделей (ну т.е. тут и меппать ничего не надо).
Могу предположить, что в OODMS все может быть еще круче и удобней и в один прекрасный день мы начнем использовать такой типа субд :)
Поведение — это воздействие на состояние.
В случае, если поведение это часть модели, то оно может изменить внутреннее состояние модели (конечно, если такое имеется). Необходимо ли реально внутреннее состояние модели — вопрос отдельный.
В случае сервисов — они могут изменить внутреннее состояние только косвенно, через доступные интерфейсы модели
Методом исключения получается в модель. Вообще, слово «модель» может иметь много смыслов, имхо в mvc модель имеется ввиду не модель сущности, а уровень бизнес логики
Но подобный уровень знаний вряд ли реально нужен, большинству требуется выучить бытовой язык, чтоб можно было читать и общаться без словаря на общие темы. В этом случае можно «схитрить» и подучить язык за довольно сжатый срок.
Сразу скажу, что я не педагог и ни на что не претендую. Проанализировав проблему изучения английского в России я выявил, что одна из основных проблем — обучение академическому английскому + очень мало практики. В итоге, школьник или студент может прекрасно знать грамматику, структуры языка и пр., но попроси его пообщаться с иностранцем, и у него ничего не выйдет.
На данный момент я достаточно свободно пишу, читаю, говорю, смотрю сериалы и тп на английском (естественно, без словарей) и начинаю учить испанский.
Для себя я решил, что у меня нет времени на долгое изучение, меня может попросту не хватить на это, я хочу добиться быстро первых результатов и надеюсь, что эффект результата будет служить стимулом двигаться дальше. Идти к педагогам или на курсы не хочу принципиально, хочу проверить смогу ли я это сделать сам :)
Я считаю, что для этого надо максимально быстро перейти к практике, общение по скайпу с носителями. Для это надо овладеть самыми основами.
Вообще, все изучения я планирую построить рекурсивно: изучая минимум чего-либо за короткий срок (1-2 мес), практика, оттачиваю нюансы, изучаю что-то более сложное и так далее.
Первая проблема с которой пришлось столкнуться — это слишком богатый грамматический мир испанского языка. Очевидно, что в реальности используется намного меньше грамматических структур. Я попытался определить, что из этого мне надо знать в первую очередь, но не смог :) Я общался с испанцами и мексиканцами, но почему-то никто не смогу мне внятно объяснить структуру основных времен. В итоге я нашел примерно то, что мне надо в каком-то учебнике по языку.
Так вот, первая стадия само-обучения: зазубрить минилекс (400 ходовых слов) и очень базовую грамматику в срок 1-2 месяц. Это должно дать возможно хоть как-то начать общение.
Вторая стадия: найти носителей и начать общаться с ними по скайпу. (найти таких можно на сайте кочсерферов)
Третья стадия определится в ретроспективе первой и второй…
Для зубрежки минилекса планирую испытать разные методики — карточки, стикеры на предметы, зубрежка в через определенные интервалы времени и перед сном, а так же карточки без русского перевода, но с картинками предметов.
Еще во времена изучения английского случайно родилась следующая методика: когда я куда-либо шел я придумывал какую-нибудь тему и на английском сам себе рассказывал. В итоге в каких-то местах я понимал, что не знаю как это сказать, приходил домой и смотрел в словаре и переводчике.
Мне кажется очень важным заучивать слова и привязывать их не к переводу, а к образу, я думаю, это должно отчасти решить проблему внутреннего перевода (т.е. говорить то, что вы хотите сказать сразу на нужном языке, а не сначала про себя подумать на русском, вспомнить все правила и тп и родить перевод).
Если все это сработает, то возможно к осени я уже хоть как-то, но смогу вести беседу на испанском. А если нет, то вряд ли смогу когда-либо осилить еще один язык :))
ИБ структуру так же нигде для этих целей не дублировали (кроме как в монго для кеширования и поиска). Поиск по API битры возвращает только ID'шники, а потом по ним из монго тянется весь объект. Где удобнее — ищем в монге. Тут суть в том, что битрикс делает доп. запросы, чтоб собраться все свойства элемента и сами запросы могут быть сложные за счет пачки join'ов. В монго же хранится «плоская» структура, т.е. объект сразу со всеми свойствами.
Когда администраторы системы меняют что-то в админке, то после сохранения срабатывает битровый хук и данные обновляются в монго.
Вообще, архитектурно ничего сверхъестественного нету, решения вполне стандартные и описанные в любом источнике по DDD.
Изначально у нас был вариант а-ля Active Records, был базовый класс сущности, который мог сохранять элемент в ИБ, от этого класса наследовались другие сущностные классы. Все свойства у классов были описаны в phpdoc нотациях, поэтому в модулях и компонентах оперировали только объектами, с нормальной поддержкой от IDE.
Но при росте сложности AR модель начинает показывать свои недостатки, вот, и поэтому переписали работу с ИБ.
Мепперы — это прослойка, которая берет сущностные классы или контексты данных и сохраняет в БД. В этом случае получается бизнес уровень полностью независимый от субд и прочего. Это дает довольно хорошие бонусы, по сути, мы можем нашу логику перенести под что угодно, например, переписать все под symfony (ну а мы, например, сделали свои high load iblock, не дождались так сказать :)). Ну, а недостаток, как я уже написал — это увеличение по сути бесполезного кода в мепперах.
Вопрос, тут на самом деле в другом, на какой черт надо городить все это в битре, потому что для сайта визитки или типового магазина данный функционал будет больше вредить. А на проектах, где реально начинают проявляться бонусы DDD, использовать битру как минимум сомнительно.
Таким образом, мы легко можем и юнит тесты писать, да и вообще делать много интересных штук (например, дублирование и синхронизацию данных ИБ в mongodb, и поиск на фронте делать по монге, что дает существенные бонусы, а если еще взять и работу с геоданными, то восторг программистов не описать словами :) )
Из минусов — естественный оверхед в dto и т.п. Но на больших проектах преимущества побеждают геморрои :)
Алгоритмика — это знания различным известных алгоритмов, плюс сообразительность, там где эти знания кончаются.
Мне кажется алгоритмика, в отличие от сообразительности, штука прокачиваемая: чем больше знаешь классических алгоритмов, связанных с ними структур данных, тем проще решить те или иные алгоритмические задачи. Это как слух развивать.
А вот сообразительность, она, как мне кажется, либо есть, либо увы нет.
С опытом проведения собеседований пришла гипотеза о том, что умный, талантливый человек — талантлив во многих областях. Поэтому чтобы определить врожденные умственные навыки можно попробовать поговорить с человеком на абсолютно разные темы, никак не связанные с ИТ или конкретной вакансией. Например, спросить что кандидат думает о текущем положении в стране, или как накормить голодающие населения Африки — рвите шаблоны, программист это не робот для кодирования, это человек, с ним можно и нужно общаться на разные темы :)
Адекватные опытные спецы давно свалили в мск/спб или работают удаленно, их рейты скорее всего выросли настолько, что уже стали больше рейтов вашей компании.
Неадекватные опытные спецы, гики и прочие, за счет своей врожденной социопатии и неумения общаться с людьми вполне могут застрять навечно в провинции. Они даже могут прийти на собеседование, но в коллективе, к сожалению, такие люди приживаются плохо, их кругозор зациклен только на технической части и не обращает внимания на другие бизнес требования, заставить что-либо их делать против их мировоззрения сложно, а если за ними пристально не следить, то вместо простого решения, вы получите космический корабль, на неизвестных технологиях. Это супер круто с технической части, но как вам с этим жить дальше?
Третий вид кандидатов — это «вчерашние» студенты. Собеседовать их — одно удовольствие. Т.е. это как анекдот, мы даже иногда зовем их на собеседование в пятницу вечером, чтоб расслабить коллектив чуточкой фана, что конечно, довольно цинично. Провинциальные вузы не учат ничему, только завышают ЧСВ — студент прослушал лекцию дотнета и считает, что он отлично знает, к примеру, сиш. Так и говорит: «Я считаю, я хорошо знаю c#». На деле же, почти никто не смог назвать ни одного паттерна.
Что такое синглтон? — мммм, не сталкивался.
Ладно, ок, Вы использовали интерфейсы? — что простите?
Интерфейсы… — ммм,
Ну, вы знаете, что такое интерфейс в c# — мммм, не сталкивался.
Даже не пытайтесь спрашивать, что либо сложное. Хотя, если только по вечерам пятницы. Надо следующих просить попкорн захватить.
Так вот, суть в сухом остатке в том, что в провинции ваше собеседование направлено не на поиск специалиста, а на поиск не совсем испорченного вчерашнего студента, которого хардкорными, унизительными вопросами приводишь к тому, что он осознает свой уровень, и если повезет, через несколько месяцев активного вправления мозга, он начинает что-то собой представлять. А еще через пару месяцев он успешно проходит собеседование в мск/спб и валит туда. Утрирую конечно, но схема очень жизненна.
Если говорить о собеседовании, то оно меняет свой формат, на технические вопросы адекватного ответа не получить, приходится придумывать, «разбалтывать» человека, что б понять его суть, что он делал, какие планы на жизнь, чем увлекается. Можно спросить про математику, но тут все настолько уныло, что даже не смешно. Такие вопросы сразу выявят сбившего с пути молодого гика, готового к перевоспитанию, а если вас угораздило делать ИТ бизнес в провинции — это без сомнений ваш вариант
2. Естественно это не ddd. Как бы об этом потом и говорится.
Интересно было б услышать Ваш вариант реализации описанной задачи в методологии DDD
В реальной ситуации у вас будет еще масса условий, в том числе и не связанных с программированием. И мой подход — это комплексный анализ всех условий.
Ведь в ddd есть еще такие понятия как value-object и aggregate model. Может быть у вас «человек» это value-object? А может и нет. Может быть у вас автобус это aggregate model и содержит человека как часть себя?
Статья — не пересказ книжки, статья — пересказ моего осмысления пачки книжек, гуглинга темы, практического опыта. Как-то так.
потому что data driven (или data centric) встречается у других довольно, на мой взгляд, авторитетных гайдлайнах о разработке (например, в гайдлайнах от майкрософта, у них вообще прямое противопоставление идет, мол если у вас приложение простецкое возможно вам стоит обратить внимание на Data Driven)
Вот, и хотя Mongo не является OODMS, но она позволяет сохранять скимлесс-документы и, да, это порой может реально упростить меппинг моделей (ну т.е. тут и меппать ничего не надо).
Могу предположить, что в OODMS все может быть еще круче и удобней и в один прекрасный день мы начнем использовать такой типа субд :)
В случае, если поведение это часть модели, то оно может изменить внутреннее состояние модели (конечно, если такое имеется). Необходимо ли реально внутреннее состояние модели — вопрос отдельный.
В случае сервисов — они могут изменить внутреннее состояние только косвенно, через доступные интерфейсы модели