Pull to refresh
14
0
Захарцев Евгений @DjoNIK

Пользователь

Send message
Ну как обогнал… В js async/await пришел из ts, ts синтаксис разрабатывает одна мелкомягкая компания, которая и реализовала этот паттерн изначально в c#.
Простите,
хантингом
?

PS: не троллинга ради, реально не понял о чем Вы.
На hh — есть комменты о работнике
К счастью, не имею опыта общения с ex-USSR-style конторами, но высокотехнологичные, модные и молодежные тоже страдают подобным. Свежий пример на личном опыте — ВК. Отказ без личного общения, лишь по полностью перекрывающему требования из вакансии резюме и полный игнор на просьбу о получении фидбека для последующего самоанализа.

Я даже подумываю, а не проводят ли они анализ интересов, сообщений в нутрях своей сети. Конспирология, конечно, но с таким не редко встречаешься.

PS: справедливости ради, признаю, что сам терялся после получения тестового задания, которое не выполнял в силу отсутствия времени/лени.
Так-то при реализации более менее сложных проектов сложно говорить в категориях хуже/лучше. Место компромиссу всегда есть. К счастью ли, к сожалению, но это факт.
интерация

Все же интернирование, ибо Ваш вариант больше похож на итерацию.
не запускается в начале

Имеется ввиду не наличие строки ldstr «abc» в самом начале кода, ибо в примере из статьи, судя по IL коду,
идет речь о методе Main из одной строчки:
Console.WriteLine("x" + "y" + "z");


По факту — компилятор «прочухал», что WriteLine-у скармливают константную строку («x»+«y»+«z» всегда то же самое, что «xyz»), а уже CLR автоматом добавит эту строку в пул интернирования еще до первой инструкции метода Main.
То есть вместо общепринятого в одном или в другом языке, давайте-ка придумаем свое, верно я понял мысль? Биндинг — изначально неправильное прочтения заимствования. Никакой оправданности или точности в нем нет (ну или я так слеп, что не могу усмотреть).
Общаетесь на русском — говорите по-русски, на английском — по-английски.
Следуя этой логике нужно сказать не биндинг, а привязка.
видимость текста
Соглашусь.
доступность кнопки
Возражу — доступность кнопки может быть обусловлена бизнес-правилами, а не UI. Если рассуждать не в контексте Кнопка, Доступность Кнопки, а в категориях Команда (отправка данных на сервер), Доступность Команды (не все поля заполнены), то вполне разумно в VM добавить такую функциональность, которую, к тому же, легко проверить тестами.
Хочу и делаю
и всё работает отлично

Серьезное заявление… проверять я его, конечно, не буду ©
Был у меня небольшой солюшн под WP 7.5 с 3+ проектами. M зависела только от утилитарного проекта и DAL; VM от M + от утилитарного; V, соответственно, от VM (без M, то есть V не знал о M вообще). При переходе 7.x->8.x->UWP мне по большому счету приходилось менять только V.

Да, мне очень помог Caliburn.Micro, позволивший не пробрасывать из V во VM *EventArg и не городить лишних зависимостей. А там где нужно было завязаться на специфические API — все решалось через DI.

Годится такой пример?
Больше свойств — больше связей, все их нужно синхронизировать и держать в голове при разработке. Конвертеры имеют меньше зависимостей.

В любом случае нужен взвешенный подход. Нельзя однозначно отказаться от конвертеров, ровно как и от подхода создания дополнительных свойств. Наверное, только с опытом придет понимания, как лучше поступить в том или ином случае. А универсальных и строго формализованных правил на этот счет сформулировать трудно.
А если разнести V, VM и M по разным проектам, то нужно прокидывать в VM сборки предназначенные только для UI.
Ну и плюс Visibility в VM тоже не здорово.
А я вот эту вот цитату не понял:
также на Windows Phone версии 8 и выше. И даже на Windows Mobile (владельцы люмий, мы про вас не забыли!)

«даже на Windows Mobile» как будто о старом добром Windows Mobile 6, но в то же время «владельцы люмий», как о Winows 10 Mobile.
Мне не нравится каждый раз делать так с git:
git add, git commit -m “Bla Bla Commment ”, git push origin master

Вместо этого я просто создал папку, а для бэкапов каждый раз делаю новую, прописывая в названии вчерашнюю дату

В контексте заголовка, кодить-то может и научился… а вот разрабатывать пока нет.
И я не придумал лучшего способа, чем взять книгу «Паттерны проектирования» Эрика и Элизабет Фримен, и написать примеры каждого паттерна на Objective-C и Swift.

Плохая идея. Паттерны, это не про реализацию набора правил, это про применение этого набора правил в подходящем для этого месте. Хотя, может и нужно пройти такого рода эволюцию:
1) паттерн головного мозга — это когда только прочитал про них и везде, чаще не к месту, применяешь их;
2) просветление — это когда реально познал дзен и можешь аргументированно рассказать почему в этом месте нужен именно этот паттерн, а при немного других вводных при той же функциональности уже нет.

Ну и да, антипаттерн — это не про тот или иной конкретный паттерн, а про неправельное его применение.
Когда я был младше, я начинал изучать документацию языка Swift

Но сейчас-то повзрослел… Зрелый язык, зрелое отношение к документации.
Так потому и в кавычках жи ))

А по поводу First Line… ну мой личный опыт таков, что я оттуда ушел спустя 4 или 5 месяцев работы, не меня уволили, а именно я искал куда бы поскорей перейти. Ушел в другую аутсорс-компанию, в которой уже почти 3 года. При сравнении однозначно скажу, что сделал правильный выбор (по многим критериям).

Не берусь утверждать, что там плохо для всех и для каждого — непосредственно контактировал с ребятами, которые там уже больше 6 лет и их устраивает.
1
23 ...

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Works in
Date of birth
Registered
Activity