«Черная магия» появляется в коде моментально, как только нет ответа на вопрос: почему так.
К сожалению за почти все 14+ лет разработки я не видел хороших вариантов именно в коде это описать и отобразить, в комментариях тоже. Не помогает и история коммитов, потому что или много изменений кода или же задача в таск трекере имеет только название и никакого анализа и описания.
Будучи архитектором, я не могу часто читать код со всеми деталями, я просто не смогу физически порой найти комментарий «почему» и буду страдать, плакать, идти к автору, если он еще работает и спрашивать почему так. И то не факт, что автор будет понимать и помнить почему так всё вышло.
Нужно описание архитектуры и бизнес истории, причем не в формате как это предлагает эджайл (или кто там это предложил) в формате: «я, как… хочу… чтобы ...» — это вот тоже не дает ответа на вопрос: «а почему ты так хочешь?». Нужны ADR и прочие архитектурные артефакты.
За сим закончу, а то начнет гореть сильно =)
Алексей, так конференции не про обучение же. А по верхам мы уже нахватались многого, вот и кажется, что все по щиколотку да как-то пресно. А?
Мне кажется получение связей — это вот важно )))
Эффект присутствия и вдохновления не срабатывает ))
Действительно технических статей не густо, даже очень. Не раз писали уже, что конкретика не вызывает ни плюсов, ни обсуждений. Только холиварные и абстрактные темы вызывают дискуссии. А на конференциях есть возможность поймать спикера и вытрясти конкретику и все такое прочее.
Конференции нужны, в качестве «принудительно-просветительких» встреч. Т.е. я, как разработчик естественно читаю много по моей фактической работе и что-то около нее, но нельзя спросить о том, чего не знаешь. В том смысле что даже не представляешь, что какая-то технология или возможность имеют место быть. На конференции, раз уж пришел, могу послушать доклады на темы о которых я не имел понятия.
Автор вполне резонно заметил, что многие доклады повторяются и с некоторыми докладами спикеры гастролируют целый год или около того, это не новость. Но если вам удалось за конференцию прослушать 2-3 вдохновляющих доклада, то конфренция удалась.
И тут еще правильно говорят, что конференции дают заряд мотивации, когда видишь, как может быть красиво решена та или иная задача. Даже решение из отдаленной области может навести на решение в вашей.
Я вот тоже до недавнего времени считал, что это общий принцип. Но наткнувшись на статью и почитав ссылки из нее, я понял, что это не так. Я так впечатлился, что решил перевести, потому что это очень важно.
Нет, «линеаризуемость» это не «сериализуемость», это совсем разные термины по статье.
Сериализация представляет собой процесс преобразования объекта в поток байтов для хранения объекта или передачи его в память, базу данных или файл. Ее основное назначение — сохранить состояние объекта для того, чтобы иметь возможность воссоздать его при необходимости. В то время как линеаризация это сохранение строго исторического порядка записей\запросов как они приходили в систему. В каком-то частном случае это может быть одно и то же.
Про Availability в статье тоже есть. И вы правы, что сейчас это относится больше к SLA и измеряется в процентах и по сути является latency.
У большинства вендоров легаси код с доисторических времен возможно. Однако если вы причастны к разработке публичных интерфейсов, то можно делать мир немного лучше в отдельно взятой эпсилон-окретсности своих клиентов.
Постоянные повторы и возвращения дискуссии могут помочь преодолеть так называемый «technology gap» значительно быстрее, на мой взгляд.
Вы все правильно говорите про плюсы идемпотентной системы, но тут суть несколько в ином, как мне кажется. API в любом из смыслов (Web, public contract, другие) должен инкапсулировать детали реализации. В статье не форсируется реализации в соответствии с точными терминами в общеупотребительном смысле. Т.е. то же редактирование элемента — это бизнес-термин, понятный бизнесу и пользователю, а вы внутри можете это реализовать как угодно, разве нет?
Я полностью за немутабельные/замораживаемые объекты, так как с ними сильно проще работать. Но построение публичного интерфейса должно строиться с использованием «общего» (ubiquitous) языка для разработчиков и аналитиков/пользователей.
Может и капитанство, если вы эксперт и уже собаку съели на этом. Однако статья полезна привлечением внимания к теме формализованности подхода против стихийности. Интуитивно многие вещи может быть и понятны, особенно для людей с высоким уровнем самоорганизации, но какие-то шаги могут быть неявными. Да, обзор общий, но это ли не повод найти и просмотреть отдельные главы книги более детально? ;)
Еще полезными являются множества ссылок на ресурсы сгруппированные по решаемым задачам на каждом этапе.
Ваш комментарий уже выполняет задачи более глубокого уровня — поднять дискуссию, что могло быть упущено. Может какие-то протоколы сложнее, или легче для определенных задач, неважно какой пункт будет обсуждаться, главное увидеть мнения и опыт.
Точно-точно! Эти баблы раздражают — сил нет просто. Кто придумал, что это удобно читать? Когда много пишешь и читаешь, то удобнее все смотреть словно это простыня текста.
А то такими темпами в книжках скоро так будут выравнивать диалоги персонажей. И аватарки к ним пририсовывать. Вот потеха будет.
Да, статья оставляет некоторое чувство недосказанности, но видимо это как обзор того, что должно быть принято во внимание при разработке хорошего API. О некоторых аспектах, упомянутых в статье даже и не задумываются многие при разговоре о том, какое должно быть API, какие функции поддерживать.
Было много про Blend, но чего-то особенного про сам XAML не рассказывали, насколько помню.
Да, такие вылеты редактора тоже раздражают, но никаких подвижек пока не сообщают. Но об этом можно написать программным менеджерам ;)
Мне кажется что с выпуском новой студии это должно уйти в релиз. В видео показывали что это уже работает из локальной репки NuGet, так что в целом это должно быть политическое решение, когда отправить это в большой мир.
Из объяснений ведущих, я понял, что будет что-то очень близкое к этому. Потому как дальнейшая нацеленность на отчуждаемость WPF движка и возможность переноса на другие ОС.
Т.е. для поздних Windows такая опция может быть не столь актуальна, но для других ОС очень даже.
Более того, такой механизм распространения и использования WPF позволит сделать релизы более частыми, а значит оперативно реагировать на запросы больших бизнесов, и вводить новые фишки, не дожидаясь основных обновлений языка. Примерно как ASP.NET. При таком подходе не будут «ломаться» разные версии приложений, так как работают с фиксированной версией WPF. Отлично же!
Может быть и как стенографистки, по количеству набираемой смысловой информации. =))
Но вообще да, правильно должно быть машинистки, но так больше понравилось.
Это не то, чтобы прямой перевод, а скорее вольное изложение с перепроверкой. Некоторые пункты в статье не соответствовали положению дел, какие-то лишь частично. Что-то дополнилось, что-то сократилось. Но в целом указать можно, как вдохновителя и отправную точку =)
Если указать, что это перевод, то будет больше наездов, что не дословно, а пересказ какой-то и мол отсебятины много. Так что взвесив все за и против, от перевода отказались.
К сожалению за почти все 14+ лет разработки я не видел хороших вариантов именно в коде это описать и отобразить, в комментариях тоже. Не помогает и история коммитов, потому что или много изменений кода или же задача в таск трекере имеет только название и никакого анализа и описания.
Будучи архитектором, я не могу часто читать код со всеми деталями, я просто не смогу физически порой найти комментарий «почему» и буду страдать, плакать, идти к автору, если он еще работает и спрашивать почему так. И то не факт, что автор будет понимать и помнить почему так всё вышло.
Нужно описание архитектуры и бизнес истории, причем не в формате как это предлагает эджайл (или кто там это предложил) в формате: «я, как… хочу… чтобы ...» — это вот тоже не дает ответа на вопрос: «а почему ты так хочешь?». Нужны ADR и прочие архитектурные артефакты.
За сим закончу, а то начнет гореть сильно =)
Мне кажется получение связей — это вот важно )))
Действительно технических статей не густо, даже очень. Не раз писали уже, что конкретика не вызывает ни плюсов, ни обсуждений. Только холиварные и абстрактные темы вызывают дискуссии. А на конференциях есть возможность поймать спикера и вытрясти конкретику и все такое прочее.
Автор вполне резонно заметил, что многие доклады повторяются и с некоторыми докладами спикеры гастролируют целый год или около того, это не новость. Но если вам удалось за конференцию прослушать 2-3 вдохновляющих доклада, то конфренция удалась.
И тут еще правильно говорят, что конференции дают заряд мотивации, когда видишь, как может быть красиво решена та или иная задача. Даже решение из отдаленной области может навести на решение в вашей.
Нет, «линеаризуемость» это не «сериализуемость», это совсем разные термины по статье.
Сериализация представляет собой процесс преобразования объекта в поток байтов для хранения объекта или передачи его в память, базу данных или файл. Ее основное назначение — сохранить состояние объекта для того, чтобы иметь возможность воссоздать его при необходимости. В то время как линеаризация это сохранение строго исторического порядка записей\запросов как они приходили в систему. В каком-то частном случае это может быть одно и то же.
Про Availability в статье тоже есть. И вы правы, что сейчас это относится больше к SLA и измеряется в процентах и по сути является latency.
Постоянные повторы и возвращения дискуссии могут помочь преодолеть так называемый «technology gap» значительно быстрее, на мой взгляд.
Я полностью за немутабельные/замораживаемые объекты, так как с ними сильно проще работать. Но построение публичного интерфейса должно строиться с использованием «общего» (ubiquitous) языка для разработчиков и аналитиков/пользователей.
Еще полезными являются множества ссылок на ресурсы сгруппированные по решаемым задачам на каждом этапе.
Ваш комментарий уже выполняет задачи более глубокого уровня — поднять дискуссию, что могло быть упущено. Может какие-то протоколы сложнее, или легче для определенных задач, неважно какой пункт будет обсуждаться, главное увидеть мнения и опыт.
А то такими темпами в книжках скоро так будут выравнивать диалоги персонажей. И аватарки к ним пририсовывать. Вот потеха будет.
Да, такие вылеты редактора тоже раздражают, но никаких подвижек пока не сообщают. Но об этом можно написать программным менеджерам ;)
Т.е. для поздних Windows такая опция может быть не столь актуальна, но для других ОС очень даже.
Более того, такой механизм распространения и использования WPF позволит сделать релизы более частыми, а значит оперативно реагировать на запросы больших бизнесов, и вводить новые фишки, не дожидаясь основных обновлений языка. Примерно как ASP.NET. При таком подходе не будут «ломаться» разные версии приложений, так как работают с фиксированной версией WPF. Отлично же!
Но вообще да, правильно должно быть машинистки, но так больше понравилось.
Если указать, что это перевод, то будет больше наездов, что не дословно, а пересказ какой-то и мол отсебятины много. Так что взвесив все за и против, от перевода отказались.