Пошел погуглить, что за аббревиатура такая «ППА».
Теперь, когда голосование еще идет, а рейтинг уже не корректируется — это принимает какой-то особый смысл
У меня есть предположение о двухлетнем пороге (в моем случае было так).
Это тот самый срок, за который накапливается достаточно экспертизы в предмете работы. И вам кажется, что можно сделать всё "правильно".
В случае с программированием — это переписать всё к хренам с нуля, например.
А в случае с управлением — изменить все процессы.
Но вот ресурс (деньги/время) на это работодатель выделять не хочет или не может (и на то могут быть вполне объективные причины).
И вот сидишь ты такой и делаешь изо дня в день, то что считаешь "неправильным". Сражаешься сам с собой, и испытываешь почти физическую боль прикасаясь к тому что "криво и косо". Я совсем не религиозен, но есть замечательная молитва, которая четко отражает душевное состояние в такой момент:
Господь, дай мне силы изменить то, что я могу изменить.
Дай смирение принять то, что изменить не в моей власти.
И мудрость, чтобы отличить одно от другого.
Тут важно просто понять, что ваша работа — это еще не вы. И пусть она себе работается… а сделать "всё правильно" можно и где-то в другом месте. Не даром, программирование входит в топ способов выхода из ступора.
Да это конченый кликбейт. Автор, походу рекламу для стрёмных сайтов раньше сочинял.
В следующей статье заголовок будет: «Чтобы избавится от вирусов на компе, нужно раз в месяц использовать обычную...»
Если поразмыслить, как может представитель бизнеса – директор, руководитель отдела, продавец, бухгалтер и т.д. – составить техническое задание на разработку программного продукта?
Эм… по ГОСТ'у например. Его потому и придумали.
Между бизнесом и программистами есть граница – языковой барьер. Бизнес не понимает языка информационных систем, программисты не понимают языка бизнеса. Чтобы хоть как-то существовать, и хоть чего-то делать, обе стороны изобрели суррогатный язык – некий аналог эсперанто, одинаково понятного и непонятного обеим сторонам.
Вам нужно почитать Эванса. В своей "большой синей книге", он подробно излагает, как правильно вырабатывать такой словарь.
Было бы здорово, конечно, если бы программисты создали отторгаемую систему, на которую бизнес посмотрел бы со стороны, и принял решение – брать или не брать.
Вы не поверите, но программисты ежедневно занимаются созданием таких систем. Так работают все SaaS решения.
Вообще, необходимость выработки общего языка давно известна. Это касается не только бизнеса, но и любого процесса который возникает необходимость автоматизировать. Вся первая часть книги "Предметно ориентированное проектирование" Эванса, посвящена именно этой проблеме. И любой, более-менее толковый специалист в области анализа и проектирования систем, прочитал ее хотя бы однажды. Если же вам попадались другие специалисты… то хреновые специалисты вам попадались.
Выработка общего словаря между условным заказчиком и условным исполнителем — вообще необходимый минимум, для создания хоть сколь нибудь сложной системы.
Для примера: на текущем проекте, нам понадобилось около полугода только для того, чтобы выработать такой словарь.
А вот выработать такой универсальный словарь для всех — на практике, почти не представляется возможным. Это слишком живой язык, и скорость его изменения не позволяет создать учебник, который был бы актуален хотя бы пару лет. Не говоря уже о бесчисленном множестве диалектов.
Опять эти люки… Как и написано в заголовке, эти вопросы действительно ужасны, и совершенно не подходят для собеседования )
Я возможно ошибаюсь, но мне почему-то кажется, что большинству работодателей, нужны кадры способные решать задачи, а не задачки… Искренне надеюсь, что эти вопросы не были взяты с реальных собеседований.
Извините, что так поздно отвечаю. Batch API — по сути очень похоже на JSON-RPC. Partial response — отлично работает с плоскими сущностями. С многомерными сущностями, наверное, тоже можно что-то придумать. То есть, из этого всего, при должном усердии, можно слепить что-то похожее на GraphQL.
Так что там по киллер-фичам? Go — просто как топор, в Rust потокобезопасная концепция владения, и copiler-driven-development. Ну типа незнаю… должно же быть хоть что-то типа «гляди как могу!». )
Я не разрабатываю админку, я разрабатываю приложение с программным интерфейсом, работающее в парадигме CRUD. Я стараюсь спроектировать API приложения таким образом, чтобы было максимально удобно написать под него генераторы интерфейса на основе интроспекции. Сегодня я понятия не имею, какие еще клиенты у этого приложения появятся в дальнейшем. Тысяч и миллионов там точно не будет, но различная вариативность будет присутствовать 100%. Уже на текущем этапе кроме админки у приложения есть еще два вида клиента (один — агрегатор данных, второй — веб-сайт (личный кабинет)). Еще планируется третий вид клиента — сдк для интеграции с нашим API. Я не написал ни строчки кода отдельно под эти клиенты, хотя наборы данных, которые используют разные виды клиентов — существенно отличаются друг от друга. Просто каждый из них использует то, что ему нужно — и я никак не вмешиваюсь в этот процесс, кроме разграничения прав.
Шаблон макроса — просто handlepars-like строка или адрес шаблона в дот-нотации.
А дальше, просто подставляем аргументы в шаблон. Полученные строки подмешиваются в исходник, и схема пересобирается еще раз. Так себе решение, но работает.
Будет одна транзакция. Запросов UPDATE будет несколько.
Вам нужно немного поработать с нормальной ORM(Datamapper) уровня Hibernate или Doctrine, чтобы понять, что это не так. У меня нет сил вам это доказывать.
Люди поработавшие с Doctrine в комментариях непременно меня опровергнут, если я не прав.
С таким аргументом и не поспоришь :)
Это было мнение. Аргументация была в следующем предложении
А там собственно таже проблема, которую я описал здесь и в прошлой статье. Она допускает значение null при апдейте. Это конечно можно проверить ручками внутри резолвера, но я искал решения, управлять этим поведением на уровне GraphQL.
Теперь, когда голосование еще идет, а рейтинг уже не корректируется — это принимает какой-то особый смысл
У меня есть предположение о двухлетнем пороге (в моем случае было так).
Это тот самый срок, за который накапливается достаточно экспертизы в предмете работы. И вам кажется, что можно сделать всё "правильно".
В случае с программированием — это переписать всё к хренам с нуля, например.
А в случае с управлением — изменить все процессы.
Но вот ресурс (деньги/время) на это работодатель выделять не хочет или не может (и на то могут быть вполне объективные причины).
И вот сидишь ты такой и делаешь изо дня в день, то что считаешь "неправильным". Сражаешься сам с собой, и испытываешь почти физическую боль прикасаясь к тому что "криво и косо". Я совсем не религиозен, но есть замечательная молитва, которая четко отражает душевное состояние в такой момент:
Тут важно просто понять, что ваша работа — это еще не вы. И пусть она себе работается… а сделать "всё правильно" можно и где-то в другом месте. Не даром, программирование входит в топ способов выхода из ступора.
В следующей статье заголовок будет:
«Чтобы избавится от вирусов на компе, нужно раз в месяц использовать обычную...»
Эм… по ГОСТ'у например. Его потому и придумали.
Вам нужно почитать Эванса. В своей "большой синей книге", он подробно излагает, как правильно вырабатывать такой словарь.
Вы не поверите, но программисты ежедневно занимаются созданием таких систем. Так работают все SaaS решения.
Вообще, необходимость выработки общего языка давно известна. Это касается не только бизнеса, но и любого процесса который возникает необходимость автоматизировать. Вся первая часть книги "Предметно ориентированное проектирование" Эванса, посвящена именно этой проблеме. И любой, более-менее толковый специалист в области анализа и проектирования систем, прочитал ее хотя бы однажды. Если же вам попадались другие специалисты… то хреновые специалисты вам попадались.
Выработка общего словаря между условным заказчиком и условным исполнителем — вообще необходимый минимум, для создания хоть сколь нибудь сложной системы.
Для примера: на текущем проекте, нам понадобилось около полугода только для того, чтобы выработать такой словарь.
А вот выработать такой универсальный словарь для всех — на практике, почти не представляется возможным. Это слишком живой язык, и скорость его изменения не позволяет создать учебник, который был бы актуален хотя бы пару лет. Не говоря уже о бесчисленном множестве диалектов.
Можно подробнее? Очень интересует практика в данном вопросе.
Я возможно ошибаюсь, но мне почему-то кажется, что большинству работодателей, нужны кадры способные решать задачи, а не задачки… Искренне надеюсь, что эти вопросы не были взяты с реальных собеседований.
А задачки интересные, конечно )
Смотря как этот react готовить. Тот же php-pm отлично работает.
А вообще, вот эта штука работает схожим образом, на сколько я могу понимать.
А дальше, просто подставляем аргументы в шаблон. Полученные строки подмешиваются в исходник, и схема пересобирается еще раз. Так себе решение, но работает.
Вам нужно немного поработать с нормальной ORM(Datamapper) уровня Hibernate или Doctrine, чтобы понять, что это не так. У меня нет сил вам это доказывать.
Люди поработавшие с Doctrine в комментариях непременно меня опровергнут, если я не прав.
Это было мнение. Аргументация была в следующем предложении