Такой живой интерес к посту не может не радовать :-)
К сожалению, всю прошлую пятницу хабр оставался для нас недоступен. Видимо, корпоративный IP был зафильтрован в процессе масштабной борьбы с DDoS-атаками. Сейчас ситуация изменилась, и в ближайшее время предоставим вам автора ;-)
Еще раз, огромное спасибо за вопросы и комментарии!
Думаю, у вас очень дисциплинированная команда, очень похвально.
Напишу именно про себя и свой опыт.
Когда мы использовали схему отслеживания commit’ов, то часть commit’ов оставлась в репозитории не проверенной.
Иногда в «запарке», я откладывал проверку на потом, а там ещё commit’ов накидали и старые уже просто лень смотреть совсем, и этого потом так у меня и не наступало.
Поэтому, дабы дисциплинировать себя самого, мы использовали инструмент, чтобы это «потом» однозначно наступало рано или поздно.
Ещё инструмент позволяет удобно отслеживать всю историю изменений и общения по конкретным блокам кода. В почтовой программе такого удобства, к сожалению, нет.
Инструмент позволяет работать с изменениями наподобие wiki движка: все комментарии видны, удобство обсуждения и хорошо отслеживается история изменений по ходу общения.
1. Мы реализуем новый функционал в отдельных ветках.
2. Каждая большая задача всегда разбивается на подзадачи.
3. Разработчик отдаёт код на инспекцию вменяемыми законченными частями.
4. Приоритет на инспекцию у нас ниже только критических уязвимостей.
Надо убедить человека совершить то или иное действие либо выдать информацию о себе. При этом говорить «я участвую в конкурсе, подыграйте мне» не стоило)
Можно и разжевать :)
Смотрите, при реализации кроссплатформенных приложений – главное, правильная архитектура, разделение кода на логические слои: GUI, бизнес-логика, слой коммуникации. В данной статье я по сути описал именно алгоритм создания такого слоя коммуникации.
Что же касается GUI – тут все плохо: для каждой платформы пишется свой GUI. Но если грамотно спроектировать приложение, то вам по сути и придется, что только перерисовать несколько вьюшек, если конечно не шибко замудренный интерфейс.
ObservableCollection — можно, но осторожно, все упирается в отсутствие нормальной поддержки generic-типов. :) Так что если вы будете работать с ObservableCollection как с необобщенной коллекцией – то попробовать можно, хотя я этого делать крайне не рекомендую. Лично я для этого написал свой класс, который реализует все не типизированные интерфейсы ObservableCollection, и горя не знаю:)
На счет XAML – должен вас огорчить. По сети давно ходят слухи, что некие энтузиасты работают над таким решением, но рабочего решения я так и не видел. Однако не все так печально: нативные библиотеки iOS и Andorid весьма богаты функционально и просты в использовании. А учитывая гайды по построению пользовательских интерфейсов – для каждой платформы должен быть свой интерфейс, учитывающий специфику платформы (поверьте, iOS пользователь, увидев на Айпаде Metro-интерфейс на долго впадет в ступор и врядли заъочет использовать ваше приложение).
Если эта тема в самом деле интересна – я могу написать по ней еще несколько статей.
Что касается дженериков – согласитесь, возможность переопределять виртуальные методы generic-типов – одно из их главных преимуществ в .NET. И отсутствие возможности реализовать IEnumerable очень сильно огорчает. Хотя тут да, вы правы, я погорячился, говоря что нет «никаких» генериков. Правильнее было бы сказать «большинства возможностей генериков».
На счет рефлексии – вы правы, тут я то же погорячился как и в предыдущем примере :) Однако согласитесь, вряд ли в клиентских приложениях потребуется сложная логика по анализу классов без возможности работы с их экземплярами. Лично мне не приходит в голову сценарий использования этого функционала.
Все записи пока у специалистов площадки, где проходил форум. Ожидаем, что они передадут нам видео на этой неделе, соответственно, как только оно окажется у нас, начнем заливать.
К сожалению, всю прошлую пятницу хабр оставался для нас недоступен. Видимо, корпоративный IP был зафильтрован в процессе масштабной борьбы с DDoS-атаками. Сейчас ситуация изменилась, и в ближайшее время предоставим вам автора ;-)
Еще раз, огромное спасибо за вопросы и комментарии!
Напишу именно про себя и свой опыт.
Когда мы использовали схему отслеживания commit’ов, то часть commit’ов оставлась в репозитории не проверенной.
Иногда в «запарке», я откладывал проверку на потом, а там ещё commit’ов накидали и старые уже просто лень смотреть совсем, и этого потом так у меня и не наступало.
Поэтому, дабы дисциплинировать себя самого, мы использовали инструмент, чтобы это «потом» однозначно наступало рано или поздно.
Ещё инструмент позволяет удобно отслеживать всю историю изменений и общения по конкретным блокам кода. В почтовой программе такого удобства, к сожалению, нет.
Инструмент позволяет работать с изменениями наподобие wiki движка: все комментарии видны, удобство обсуждения и хорошо отслеживается история изменений по ходу общения.
Меня в свою команду вы, видимо бы не взяли :)
1. Мы реализуем новый функционал в отдельных ветках.
2. Каждая большая задача всегда разбивается на подзадачи.
3. Разработчик отдаёт код на инспекцию вменяемыми законченными частями.
4. Приоритет на инспекцию у нас ниже только критических уязвимостей.
Смотрите, при реализации кроссплатформенных приложений – главное, правильная архитектура, разделение кода на логические слои: GUI, бизнес-логика, слой коммуникации. В данной статье я по сути описал именно алгоритм создания такого слоя коммуникации.
Что же касается GUI – тут все плохо: для каждой платформы пишется свой GUI. Но если грамотно спроектировать приложение, то вам по сути и придется, что только перерисовать несколько вьюшек, если конечно не шибко замудренный интерфейс.
ObservableCollection — можно, но осторожно, все упирается в отсутствие нормальной поддержки generic-типов. :) Так что если вы будете работать с ObservableCollection как с необобщенной коллекцией – то попробовать можно, хотя я этого делать крайне не рекомендую. Лично я для этого написал свой класс, который реализует все не типизированные интерфейсы ObservableCollection, и горя не знаю:)
На счет XAML – должен вас огорчить. По сети давно ходят слухи, что некие энтузиасты работают над таким решением, но рабочего решения я так и не видел. Однако не все так печально: нативные библиотеки iOS и Andorid весьма богаты функционально и просты в использовании. А учитывая гайды по построению пользовательских интерфейсов – для каждой платформы должен быть свой интерфейс, учитывающий специфику платформы (поверьте, iOS пользователь, увидев на Айпаде Metro-интерфейс на долго впадет в ступор и врядли заъочет использовать ваше приложение).
Если эта тема в самом деле интересна – я могу написать по ней еще несколько статей.
На счет рефлексии – вы правы, тут я то же погорячился как и в предыдущем примере :) Однако согласитесь, вряд ли в клиентских приложениях потребуется сложная логика по анализу классов без возможности работы с их экземплярами. Лично мне не приходит в голову сценарий использования этого функционала.