Достаточно быть кандидатом наук, чтобы не попасть в армию. Насчёт заболеваний. Я слышал, что разные военкоматы по-разному относятся к заболеваниям. Ну и, скажем так, если у вас найдут что-то эдакое, из-за чего у вас могут очень серьёзные проблемы, то могут побояться забрать.
А так да, я не успел диплом защитить, как ко мне уже ходить на дом начали.
Неа. У меня Nokia C3. Миллион, как вам сказали, не слишком много. Это был пункт экономического обоснования.
А вот у вас, вероятно, какие-то психологические проблемы, раз вас так айфоны беспокоят.
Нет. Не дают. Вы ошибаетесь. Имейте это ввиду.
А ещё вам не дадут отсрочку, даже если у вас есть ребёнок. Даже больше скажу, если у вас есть ребёнок и жена беременна вторым, то вам отсрочку тоже не дадут при условии, что жена уже не на 6-м или 7-м месяце, не помню точно. То есть, если на пятом — то заберут. А вот если на 6-м — не заберут.
Дебилы в армии, дебилы принимают законы и бог знает сколько таких дебилов.
Зарабатываю чуть больше миллиона рублей в год сейчас. В аспирантуре защититься не дают. В ноябре заканчивается отсрочка. И что — мне идти в армию? На целый год? Я за год читаю сотни статей и десятки книг. С учётом того, что зарабатываю я в год на 7 военных билетов по рыночной цене в 150 тысяч — пошли все эти дебилы с выравниванием сугробов в жопу.
Ничего подобного. Не произойдёт запоминание. Почти всегда, то, что не используется достаточно долго, забывается напрочь. Бывает, что нечто редкое наглухо врезается в память, но это большая редкость.
Конечно. Но в статье не про кишки, а про безголовость.
Кстати, чтобы быть хорошим разрабом, не надо знать кишки платформы.
Любой разраб, столкнувшись с непонятным поведением, может прогуглить это поведение.
Для хорошего разработчика, который лабает на C++, Haskell, C#.NET, F#.NET всю эту бредятину запомнить невозможно. Лучше Кнута почитать.
Я ни раз видел в подкастах как тот же Roy Osherove натыкается на непонятку и просто гуглит её.
Абсолютно согласен.
Есть редкие и полезные факты. А в этой статье почти всё — редкие и бесполезные факты.
1. 95% программистов НИКОГДА не воспользуются этим видом индексатора. Вообще никогда.
2. Тоже самое хотел сказать. Интернирование настраиваемо. И, кстати, надо разобраться, там, по-моему в разных версиях .NET, настройки по умолчанию разные.
9. Также согласен. Бесполезный факт на 100%.
10. За такие вызовы вообще сразу ссаной тряпкой по морде надо бить.
Вот такие «обнаружатели интересных фактов» потом мучают джуниоров, а то и мидлов на собеседованиях всяким бредом.
1. Перечисления повышают безопасность использования типов. Например, при определении константных значений для Interop, предпочтительнее воспользоваться enum, а не множеством из const-членов.
2. Предпочту switch там, где нет необходимости во всяких паттернах типа «стратегии».
3. Флаговые перечисления бывают катастрофически полезными.
Сомневаюсь, что я привёл полный список аргументов «за» использование перечислений.
Я могу напомнить как удобно работать с DependencyProperty. Их нагороженные объектные модели сделали сложное там, где можно было и попроще.
А ещё это объясняет почему WPF так требователен к ресурсам. Он мог бы быть куда менее требовательным. Но нет, ему надо внутри вызывать сотни методов с 10 аргументами, множество из которых надо откопировать.
Сказать «здесь проблема в железе» — ничего не сказать. В нашем случае, что сказали бы разрабы? — «Спасибо, кэп», но нам от этого не легче, а заказчик не собирается обновлять парк машин. А ещё вам только кажется, что железо за 100$ на ура тянет любые WPF-приложения уровня point of service. Это раз. Ну и про реализацию самого WPF что вы скажете?
Ну и последнее, чем плох WinForms для стандартных desktop-приложений? Столько все писали под MFC, под Delphi, под WinForms, потом бах — «фууу, WinForms — говно, как жеж можно использовать таких древних мамонтов?».
По факту, ИМХО, львиная доля потребностей заказчиков в случае стандартного десктопного приложения покрывается WinForms + ADO.NET. Стандартный набор.
Рискую заполучить минусов, но я не могу не высказаться.
Хоть убейте меня, я ну никак не могу понять, почему все считают, что нельзя брать в расчёт WinForms?
Да, я согласен, что в WPF полно плюшек, но…
Мы скоро начнём переписывать проект, написанный под WPF на WinForms.
Есть целый парк машин, которые пашут под Windows POS Ready 2009 и имеющие следующие характеристики: Celeron 1.8 Ghz, 512Mb DDR1, древняя встроенная видеокарта без аппаратного ускорения. Под такой платформой WPF работает медленно, ещё и глючит с отображением айтемов из ComBox, например. А вот аналог, написанный на Delphi, работает шикарно.
WinAPI, на котором зиждится WinForms, вылизан до мозга костей, а WPF — нет. Если постараться, то под WinForms можно сделать достаточно симпотичный интерфейс.
Вы вообще видели внутренний код WPF? Загляните в длиннющий StackTrace после какого-нибудь исключения. Вы увидите мириады вызовов методов, которые принимают с десяток аргументов. С десяток! Что это за говнокод? Кто все эти люди, которые такое понаписали?
Такое ощущение, что мимо Майкрософта проходил талантливый инженер, который предложил идею WPFa, Майкрософту она понравилась и её реализовали… реализовали бог знает кто, кто-то уровня человека, который реализовал SerialPort в .NET.
Вот когда видишь такую реализацию становится неприятно использовать это.
Наш новый тимлид сказал решительное нет WPFу.
Я не считаю WPF плохой технологией, но видит бог, реализовать можно было и получше.
К сожалению, ничего особого на ум не приходит. Я, питаясь по крупицам из разных источников + на сосбтвенной практике ушёл за пределы того, о чём здесь повествуется.
Марк же, хвалил эту книгу. (признаюсь честно, прочитав её оглавление, впечатлён не был — но это, правда, ещё ничего и не значит. В целом, склонен доверять в выборе того, что почитать, Марку)
Ещё хотелось бы сказать, что TDD идёт рука об руку со всеми принципами Unit Testing. То есть, они в нём сохраняются, а по сему, очень полезными будут любые источники по Advanced Unit testing.
Я помню как я убил Мандриву, сделав некорректные сетевые настройки. Тогда я понял, что слава Linux'а, как системы, «которая никогда не падает» — не более чем преувеличение.
И не планируйте. Скоро Рой выпустит вторую версию. Задумайтесь о том, чтобы её перевести как можно раньше. Поверьте, сообщество профессионалов это оценит. The Art of Unit Testing — библия для начинающих в Unit Testing.
если функцию при ее текущем функционале нельзя подвергнуть рефакторингу, она тривиальна.
Не совсем. Я бы перефразировал как-то. Практически формула, но звучит немного кривовато, что-ли.
Порядок программирования пропадает. Для TDD это важно.
Откуда взялся текущий функционал?
Когда я хочу перефразировать, то, что вы сказали, получается что-то типа:
«Если предполагаемая реализация функционала не сможет быть подвергнута рефакторингу, то эта реализация тривиальна и тесты на неё не требуются.»
Чувствуете, чего я хочу от формулировки? То как я переформулировал мне тоже не нравится.
А так да, я не успел диплом защитить, как ко мне уже ходить на дом начали.
А вот у вас, вероятно, какие-то психологические проблемы, раз вас так айфоны беспокоят.
А ещё вам не дадут отсрочку, даже если у вас есть ребёнок. Даже больше скажу, если у вас есть ребёнок и жена беременна вторым, то вам отсрочку тоже не дадут при условии, что жена уже не на 6-м или 7-м месяце, не помню точно. То есть, если на пятом — то заберут. А вот если на 6-м — не заберут.
Дебилы в армии, дебилы принимают законы и бог знает сколько таких дебилов.
Накипело. Хотел высказаться.
p.s. Да, забыл, у меня в июле ещё свадьба.
Кстати, чтобы быть хорошим разрабом, не надо знать кишки платформы.
Любой разраб, столкнувшись с непонятным поведением, может прогуглить это поведение.
Для хорошего разработчика, который лабает на C++, Haskell, C#.NET, F#.NET всю эту бредятину запомнить невозможно. Лучше Кнута почитать.
Я ни раз видел в подкастах как тот же Roy Osherove натыкается на непонятку и просто гуглит её.
Абсолютно согласен.
Есть редкие и полезные факты. А в этой статье почти всё — редкие и бесполезные факты.
1. 95% программистов НИКОГДА не воспользуются этим видом индексатора. Вообще никогда.
2. Тоже самое хотел сказать. Интернирование настраиваемо. И, кстати, надо разобраться, там, по-моему в разных версиях .NET, настройки по умолчанию разные.
9. Также согласен. Бесполезный факт на 100%.
10. За такие вызовы вообще сразу ссаной тряпкой по морде надо бить.
Вот такие «обнаружатели интересных фактов» потом мучают джуниоров, а то и мидлов на собеседованиях всяким бредом.
1. Перечисления повышают безопасность использования типов. Например, при определении константных значений для Interop, предпочтительнее воспользоваться enum, а не множеством из const-членов.
2. Предпочту switch там, где нет необходимости во всяких паттернах типа «стратегии».
3. Флаговые перечисления бывают катастрофически полезными.
Сомневаюсь, что я привёл полный список аргументов «за» использование перечислений.
А ещё это объясняет почему WPF так требователен к ресурсам. Он мог бы быть куда менее требовательным. Но нет, ему надо внутри вызывать сотни методов с 10 аргументами, множество из которых надо откопировать.
Ну и последнее, чем плох WinForms для стандартных desktop-приложений? Столько все писали под MFC, под Delphi, под WinForms, потом бах — «фууу, WinForms — говно, как жеж можно использовать таких древних мамонтов?».
По факту, ИМХО, львиная доля потребностей заказчиков в случае стандартного десктопного приложения покрывается WinForms + ADO.NET. Стандартный набор.
Хоть убейте меня, я ну никак не могу понять, почему все считают, что нельзя брать в расчёт WinForms?
Да, я согласен, что в WPF полно плюшек, но…
Мы скоро начнём переписывать проект, написанный под WPF на WinForms.
Есть целый парк машин, которые пашут под Windows POS Ready 2009 и имеющие следующие характеристики: Celeron 1.8 Ghz, 512Mb DDR1, древняя встроенная видеокарта без аппаратного ускорения. Под такой платформой WPF работает медленно, ещё и глючит с отображением айтемов из ComBox, например. А вот аналог, написанный на Delphi, работает шикарно.
WinAPI, на котором зиждится WinForms, вылизан до мозга костей, а WPF — нет. Если постараться, то под WinForms можно сделать достаточно симпотичный интерфейс.
Вы вообще видели внутренний код WPF? Загляните в длиннющий StackTrace после какого-нибудь исключения. Вы увидите мириады вызовов методов, которые принимают с десяток аргументов. С десяток! Что это за говнокод? Кто все эти люди, которые такое понаписали?
Такое ощущение, что мимо Майкрософта проходил талантливый инженер, который предложил идею WPFa, Майкрософту она понравилась и её реализовали… реализовали бог знает кто, кто-то уровня человека, который реализовал SerialPort в .NET.
Вот когда видишь такую реализацию становится неприятно использовать это.
Наш новый тимлид сказал решительное нет WPFу.
Я не считаю WPF плохой технологией, но видит бог, реализовать можно было и получше.
В каком случае, скажем так, Caliburn'а + Unity перестанет хватать?
Но на ум кое-что, всё-таки, приходит: курсы Марка Симена на плюралсайте.
Марк же, хвалил эту книгу. (признаюсь честно, прочитав её оглавление, впечатлён не был — но это, правда, ещё ничего и не значит. В целом, склонен доверять в выборе того, что почитать, Марку)
Ещё хотелось бы сказать, что TDD идёт рука об руку со всеми принципами Unit Testing. То есть, они в нём сохраняются, а по сему, очень полезными будут любые источники по Advanced Unit testing.
Не совсем. Я бы перефразировал как-то. Практически формула, но звучит немного кривовато, что-ли.
Порядок программирования пропадает. Для TDD это важно.
Откуда взялся текущий функционал?
Когда я хочу перефразировать, то, что вы сказали, получается что-то типа:
«Если предполагаемая реализация функционала не сможет быть подвергнута рефакторингу, то эта реализация тривиальна и тесты на неё не требуются.»
Чувствуете, чего я хочу от формулировки? То как я переформулировал мне тоже не нравится.