Компилировать в студии – редкий изврат т.к. оно блонирует ui да и вообще, неприкольно. Открываем консоль, а там msbuild /t:Rebuild /p:Configuration=Release /m:16 MySolution.sln и смотрим как решение компирируется отдельно от студии в 16 процессах.
Ну на самом деле «Google Жужжание» и «Google Суматоха» — это слишком. Нужно знать меру.
А вообще тут вся проблема в том, что русский язык отчасти устарел и такие словечки в нем звучат ужаснейше глупо, вот и все.
Видимо, проблема в том, что основная коммерциализация и брэндизация английского языка проходила во второй половине 20-ого века, а в СССР язык стоял на месте и не развивался соответственно технологиям. Взять хоть ту же ЭВМ, лол.
Есть такой противный стереотип среди всяких «интеллигентов» среднего возраста, что русский язык, якобы, — самый богатый в мире. Но, к сожалению, он такой устарелый и неточный, что кучу слов просто нельзя употреблять в более-менее трезвой, современной, литературной речи. Меня, например, тошнит от таких слов, как «певец», «певица», «эстрада», «ансамбль» (последнее вообще жесть). Но это — лишь малая часть.
Английский язык в этом плане стократ лучше, он гибкий, точный, четкий и понятный.
Жужжание, суматоха, каламбур, умора.
К сожалению, придется обходиться тем, что есть.
Этот комментарий отчасти обусловлен моей неприязнью к псевдопочитателям языка, «искусства», сюда же можно приписать «кто книг не читает — тот дебил, книги — это всё» и прочее.
Постсоветские стереотипы, к сожалению. На Западе все куда более нормально. Там книги любят и читают все, потому что это просто интересно и круто. А у нас это сомнительное развлечение для «интеллигентов», и их никто не читает.
Сюда же и «языки — реки, а русский — океан!». В русском языке в среднем 150к слов, в английском в среднем — 600к, в современном (тут как раз и дает о себе знать прогресс, которого в русском куда меньше) — 1кк.
У нас с другом даже мем есть. Говорить быдло-голосом и употреблять всякие дебильно звучащие слова, вроде «каламбур» и «игра слов».
Меньше читайте теоретиков программирования, ну или хотя бы меньше им верьте. И будет вам счастье.
Си++ действительно перегрузили лишними абстракциями, но вы не обязаны всем этим пользоваться. С появлением auto язык вообще потихоньку превращается в почти человеческий, оставляя при при этом возможность писать быстрый код… Ну и вообще у вас проблемы не с Си++; в java, php и даже javascript ситуация часто та же самая.
Вам просто забили голову ерундой. Класс Бога, делегирование, абстрактные фабрики, обязательные тривиальные геттеры/сеттеры… Если от вас требуют эту ерунду на работе, меняйте работу.
Добавить геттер/сеттер атрибута в живой проект, если он вдруг понадобится — тривиальная задача, решаемая за пару минут. Пара запусков Find in files, а дальше компилятор подскажет те два с половиной случая, где надо подправить руками. Не надо их создавать на всякий случай, «чтобы были», вы не лабораторную в институте делаете.
Делегирование, фабрики-шмабрики тоже в мусорку. Самое главное — это правило третьего раза: никаких лишних абстракций (функций, классов, интерфейсов), до тех пор пока вы не скопипастите какой-то кусок кода в третий раз. Выполнять это правило нужно абсолютно строго. Даже если вы точно знаете, что третий копипаст вам нужно будет сделать через месяц — ни в коем случае не создавайте абстракцию сейчас. Вот через месяц и создадите, когда понадобится. Это правило вообще нужно писать большими красными буквами на каждой странице каждой книги по паттернам, прости Господи, проектирования.
Нормальная функция должна занимать 10-30 строк в идеале; ну хотя бы 5. Нет, ну бывают конечно функции для «синтаксического сахара», но речь не о них. Человеку банально удобно работать с функцией на одной странице, когда она вся перед глазами и не надо никуда прыгать. Странично-слайдовое мышление, семь объектов и всё такое. Никто не убьет котенка, если вы залезете в соседний класс и вызовете его функции напрямую, без делегирования и подъема десятка интерфейсов, если того требует логика вашей программы. И если класс чего-то вроде «документ» или «главное окно» имеет 300 или даже 500 членов — совершенно ничего плохого в этом нет, это действительно год-класс для вашего приложения, который так или иначе отвечает за всё.
Да, по сегодняшним меркам подобный код, если мягко, «немодный» и даже «попахивает говнокодом», но это всё понты и шелуха. Если её отбросить, то код получается очень простым и понятным, его банально в три раза меньше, и главное он пишется очень быстро. Программист должен решать задачи, а не создавать абстракции.
Все три проблемы одинаково хорошо решаются простым алгоритмом:
1) Нормализируем гистограмму по каналам
2) Делаем High-Pass
3) Если изображение получилось малоконтрастным — нормализируем еще раз
4) Выбеляем светлое, зачерняем черное.
Человеку «на глаз» это сделать легко. А для автоматики нужно будет «натренировать» алгоритм (подобрать оптимальные коэффициенты), или предоставить, опять же, несколько вариантов на выбор пользователю.
ну, на самом деле статья у Джоела сумбурная, там можно выделить аж несколько тезисов (которые довольно-таки общеизвестны, но Джоель всегда славился тем, что обрекал прописные истины в слова):
1. В университетах отдаётся предпочтение теоретическим курсам за счёт урезания практической подготовки, в результате чего выпускники совершенно не готовы к профессиональной деятельности, причём чем приестижнее университет, тем более оторваны выпускники от реальности.
2. В этом есть и положительные стороны, т.к. благодаря такому подходу в голову студентам попадают таки-хорошие вещи типа Схемы и Питона. На этом положительные стороны заканчиваются.
3. От студентов можно добиться некоего подобия продуктивной работы путём жёсткого внешнего контроля через промежуточные дедлайны.
4. «невероятно, но факт» — опытные профессионалы качественно от студентов в этом плане не отличается — тоже просрут все сроки, дай только им такую возможность.
Если уж я взялся комментировать статью, то стоит сказать, что при трезвом взгляде, статья ни о чём. Первый тезис «студенты ничего не умеют» избит и общеизвестен, остальные можно объединить в «программисты — разгильдяи». С такой точки зрения непонятно зачем писать «если студентам дать доллгосрочное задание, то они просрут все сроки», ведь в этом нет ничего удивительного, раз состоявшиеся профессионалы ведут себя, в принципе, так же.
Вначале Джоел говорит в таком тоне, будто противопоставляет неумение студентов работать по графику умению состоявшихся программистов это делать, но в конце всё смазывает упоминанием, что программисты так работают под влиянием менеджеров, а не от хорошей жизни. Это, разумеется, очень спорный вопрос и другие авторы имеют другие мнение, но подобное противоречие внутри одного коротенького эссе как минимум странно. Кроме того, тут Джоел противоречит и некоторым более ранним своим статьям.
В результате сей текст напоминает поток сознания в виде размышлений на тему несовершенства мира, в которых родилась истина «программисты — разгильдяи». Я это понял когда перевод был уже почти завершен, поэтому решил всё-же опубликовать, хотя особой ценности статья и не представляет.
Google уже вкладывает сотни миллионов долларов в Farmville
пздц :(
Вспомнилось интервью с Рэем Бредбери:
— В 1950 году вы написали книгу, принёсшую вам всемирную славу, — сборник рассказов «Марсианские хроники». Там говорилось: уже к началу второго тысячелетия на Марсе будут поселения, целые города землян. Как вы думаете, почему этого в итоге так и не произошло?
— Меня часто про такое спрашивают, и я люблю фантазировать над ответами. Ответ сегодняшнего дня: потому что люди — идиоты. Они сделали кучу глупостей: придумывали костюмы для собак, должность рекламного менеджера и штуки вроде айфона, не получив взамен ничего, кроме кислого послевкусия. Человечеству дали возможность бороздить космос, но оно хочет заниматься потреблением — пить пиво и смотреть сериалы.
Ну я решил эту проблему с выводом просто. Открыл счет на Кипре(в москве, открытие бесплатное, положил на счет 200 евро, 70 списали за доставку авиа почтой карты и интернет доступа) и всё, открыл paypal на кипровский счет, отправил реквизиты и выписку с банковского счета на верификацию лимитов, и всё… получать могу неограничено, так же не проблема к аккаунту в moneybookers привязать вывод на кипровский счет, выводиться быстро и кописия 2euro — это фигня(точнее 1.8 евро)… так перекидываю деньги с российского счета на кипровский… советую многим так поступить!!!
Вы исходите из предпосылки, что массовость определяет полезность. Продолжая вашу логику: каждый житель планеты Земля производит дефекацию минимум раз в день. Вывод: говно популярнее пхп. Вывод: даже говно лучше, чем пхп. (кстати, в этом выводе что-то есть)
Пример из жизни в мою бытность лаборантом кафедры ИТ.
Защита дипломов. Сначала выходит первый студет и гордо показывает «свою уникальную разработку» — пустышку на Joomla, причём не стесняется даже вставлять содранные с сайта UML диаграммы. Каждый слайд красочный, сочный, полон эффектов и градиентов. Ещё бы! Основная часть времени на диплом заняла как раз та самая призентация. Комиссия радостно кивает головами. Красиво же.
Второй студент рассказывает про какую-то мегакрутую нейросеть, которая позволяет выполнить какие-то полезные задачи на реальном производстве (есть даже акт о внедрении). Проделана огромная работа, студент еле уложился в печатный объём. Однако, все слайды его презентации — куча «скучных» формул черным шрифтом на белом фоне. Собственно, «весёлые» нейросети в природе встречаются редко. Комиссия сидит с пасмурными лицами. Единственный вопрос: «Вы не могли сделать повеселее презентацию?».
Потроллю немножко. :-) Самое интересное, что несмотря на весь свой «монополизм», на статус «мировой империи добра/зла», на — казалось бы — кучу сфер, в которой у Гугла есть продукты, на миллионы пользователей и т.п. — Гугл никому не нужен. Совсем. Стоит в один прекрасный/ужасный день вдруг Гуглу пропасть — это, конечно, все заметят и обсудят, но буквально на следующий день переключатся на продукты и сервисы других компаний без малейшего напряга. У Гугла нет ни одного незаменимого продукта. Даже окружение, которое кормится на «объедках с барского стола» моментально в случае необходимости перейдет на использование других средств заработка.
А ведь инфраструктурный монополист (а в современном мире почти все монополисты инфраструктурные, да и в прошлом неинфраструктурные монополии обычно были в форме картелей, что все-таки немного другое) обычно предлагает продукт, который очень трудно заменить (говоря экономическим языком — продукт с низкой эластичностью спроса по цене, у которого нет субститутов)! Представьте, что вдруг исчезнет РЖД или Микрософт, или, например, какой-то большой представитель телекомов… Но к Гуглу, как уже было сказано выше, это все не относится. А значит, если его признают монополией и начнут «давить», то всем будет глубоко плевать — проблемы Гугла волнуют только Гугла.
Любопытно, что Гугл все это прекрасно понимает и из кожи вон лезет, чтобы стать незаменимым. Но пока ничего из этого не получается. И его будущее как «империи» во многом зависит именно от того, сможет ли он таковым стать.
<...> когда недавно на сцене Стив Джобс с гордостью представлял «уникальную новую возможность», добавленную в управление камерой iPhone — делать фотографии используя кнопку добавления громкости. Джобс охарактеризовал это «фантастическим новым способом быстро запечатлеть момент, не открывая приложений и не ожидая их загрузки».
Подмена фактов. На последней WWDC эту возможность презентовал Скотт Форстолл и вот что он сказал по этому поводу: «and you even can use the volume up button now to click the photo». Всё.
Мудрость индейцев Дакоты гласит: если ты заметил, что скачешь на дохлой лошади, – слезь с неё.
Но в жизни мы часто руководствуемся другими стратегиями:
– достаём более крепкий кнут;
– меняем всадника;
– говорим себе: «мы и раньше скакали на дохлой лошади»;
– создаём рабочую группу для изучения дохлой лошади;
– посещаем разные места, чтобы посмотреть, как скачут на дохлых лошадях там;
– создаём отдел по оживлению дохлой лошади;
– устраиваем тренировки, чтобы научиться лучше скакать на дохлой лошади;
– проводим сравнительный анализ всевозможных дохлых лошадей;
– изменяем критерии, устанавливающие, что лошадь мертва;
– нанимаем на стороне людей, якобы умеющих скакать на дохлой лошади;
– внушаем себе, что ни одна лошадь не может быть настолько дохлой, чтобы на ней нельзя было скакать;
– проводим исследования, чтобы узнать, есть ли более хорошие или более дешёвые дохлые лошади;
– объясняем себе, что наша дохлая лошадь быстрее, лучше и дешевле, чем другие;
– создаем совет по качеству, чтобы найти применение дохлым лошадям;
– пересматриваем условия работы для дохлых лошадей;
– расширяем сферу применения дохлых лошадей;
– и, наконец: образуем особый отдел, в котором изучают потребности именно дохлых лошадей.
У СССР не было экономических показателей. Или вы про тонно-километры и план по лампочкам в киловаттах?
Если найдёте или знаете источник по реальным экономическим показателям СССР, типа, инфляции, монетарных индексов, внешнего торгового баланса то киньте ссылку.
А Сталин лично никого не расстреливал. Он был вирулентный параноик и сам всего жутко боялся. Он просто кастрировал всё население на сто лет вперёд. Заразил всех своим животным страхом.
Ты просто ничего не знаешь об истории своей страны. Не знаешь кто за что боролся, кто выстоял, кто победил и сколько миллионов стёрли в лагерную пыль и сколько сотен миллионов так тихо и серо как рабы прожили тут и умерли в этом болоте не имея возможности на простую и понятную человеческую жизнь, оставив в наследство только таких же забитых и серых детей.
Вся беда в том что надо бороться не с олигархами и чиновниками, а такими как ты, а вас 90%. Тех для кого свобода, честь, собственность, демократия важнее чем благосостояние чиновников, их очень мало. Остальные думают, что если у Путина всё в порядке то и им хорошо. С этим невозможно бороться. Это проклятие.
Не считаю себя «TDD гурой» :), но попробую ответить.
Во-первых, в этой статье опять допустили классическую ошибку по этой теме: смешали TDD и умение писать юнит-тесты. Это 2 абсолютно разных вещи: TDD — это техника записи тестов перед кодом, юнит-тесты — это юнит-тесты :) Поэтому прежде чем практиковать TDD, научитесь писать юнит-тесты и не пытайтесь делать это одновременно — потратите много усилий и вероятно будете разочарованы. Умение писать юнит-тесты — такой же навык, например, как работа с регулярными выражениями. Вначале тяжело, а потом разбираешься и привыкаешь.
По юнит-тестам: уже рекомендованный выше Ошроув (маст-рид) и более академический Мессарош (xunit test patterns).
По ТДД: обе книги Кента Бека «TDD в примерах» и XP, они обе в сети есть.
Еще по архитектуре рекомендую «Чистый код» Р. Мартина («дядя Боб»)
Во-вторых, написание тестов для legacy-приложений, т.е. тех где в архитектуру не была заложена тестируемость (и у которых обычно отсутствуют тесты) — одна из самых сложных задач, под силу только test-гуру. Об этом почему-то практически все забывают. Если вы только начинаете с тестами — не беритесь за это в одиночку, лучше пригласите наемного специалиста и выделите на это бюджет (деньги/время).
В-третьих, обязательно нужно разделять виды тестов: юнит-тесты (про которые везде пишут), интеграционные тесты и системные тесты (про вторые и третьи намного меньше).
Юнит — все знают, тестируется один класс без внешних зависимостей (файловая система, бд, сеть — это заменяется заглушками). Работают везде, очень быстры, покрывают максимум кода.
Интеграционные тесты — тестируется взаимодействие нескольких классов вместе, по характеристикам обратны юнит-тестам: обычно внешние системы не подменяются, нужна настройка окружения, выполняются намного дольше, покрывают только нужные куски кода.
Системные тесты — тестируют систему сверху донизу, являются выполняемым ТЗ заказчика. Похожие на интеграционные тесты, но затрагивают всю систему, поэтому обычно выполняются еще дольше, сюда также относится тесты UI, внешних сервисов и т.п.
Очень важно разделять тесты в разные папки по типам, иначе они перемешаются и сложности настройки и эксплуатации интегр. и системных тестов убьют желание у разработчиков запускать вообще что бы то ни было.
1. Тесты зависят не от архитектуры, а от требований заказчика. Если — архитектура поменялась, а требования нет — тесты нужно подстроить под новую архитектуру. В плане ТДД — тесты меняются до изменения кода, поэтому «изменение архитектуры» происходит одновременно с изменениями тестов. Смысл ТДД — тесты двигаются чуть впереди кода и все действие идет маленькими шажками.
2. Тестирование элементарных блоков — это юнит, все зависимости подменяются моками. На все их писать необязательно, если метод очень простой (например, обычный геттер/сеттер), то только время убьете. Или у вас есть функция которая выполняет запрос к базе, типа такой:
function getClients($id) {
return $this->db->query("SELECT * FROM clients WHERE id = $id");
}
смысла писать на нее юнит-тест нет, а вот интеграционный — стоит.
Написание тестов до основного кода очень сильно влияет на конечную архитектуру приложения, она сама начинает делиться на слои, что в итоге дает более удобную и гибкую архитектуру.
Основное правило: если вам тяжело писать тест — меняйте архитектуру.
Пишите тесты и все у вас получится :)
msbuild /t:Rebuild /p:Configuration=Release /m:16 MySolution.slnи смотрим как решение компирируется отдельно от студии в 16 процессах.А вообще тут вся проблема в том, что русский язык отчасти устарел и такие словечки в нем звучат ужаснейше глупо, вот и все.
Видимо, проблема в том, что основная коммерциализация и брэндизация английского языка проходила во второй половине 20-ого века, а в СССР язык стоял на месте и не развивался соответственно технологиям. Взять хоть ту же ЭВМ, лол.
Есть такой противный стереотип среди всяких «интеллигентов» среднего возраста, что русский язык, якобы, — самый богатый в мире. Но, к сожалению, он такой устарелый и неточный, что кучу слов просто нельзя употреблять в более-менее трезвой, современной, литературной речи. Меня, например, тошнит от таких слов, как «певец», «певица», «эстрада», «ансамбль» (последнее вообще жесть). Но это — лишь малая часть.
Английский язык в этом плане стократ лучше, он гибкий, точный, четкий и понятный.
Жужжание, суматоха, каламбур, умора.
К сожалению, придется обходиться тем, что есть.
Этот комментарий отчасти обусловлен моей неприязнью к псевдопочитателям языка, «искусства», сюда же можно приписать «кто книг не читает — тот дебил, книги — это всё» и прочее.
Постсоветские стереотипы, к сожалению. На Западе все куда более нормально. Там книги любят и читают все, потому что это просто интересно и круто. А у нас это сомнительное развлечение для «интеллигентов», и их никто не читает.
Сюда же и «языки — реки, а русский — океан!». В русском языке в среднем 150к слов, в английском в среднем — 600к, в современном (тут как раз и дает о себе знать прогресс, которого в русском куда меньше) — 1кк.
У нас с другом даже мем есть. Говорить быдло-голосом и употреблять всякие дебильно звучащие слова, вроде «каламбур» и «игра слов».
Выговорился.)
Си++ действительно перегрузили лишними абстракциями, но вы не обязаны всем этим пользоваться. С появлением auto язык вообще потихоньку превращается в почти человеческий, оставляя при при этом возможность писать быстрый код… Ну и вообще у вас проблемы не с Си++; в java, php и даже javascript ситуация часто та же самая.
Вам просто забили голову ерундой. Класс Бога, делегирование, абстрактные фабрики, обязательные тривиальные геттеры/сеттеры… Если от вас требуют эту ерунду на работе, меняйте работу.
Добавить геттер/сеттер атрибута в живой проект, если он вдруг понадобится — тривиальная задача, решаемая за пару минут. Пара запусков Find in files, а дальше компилятор подскажет те два с половиной случая, где надо подправить руками. Не надо их создавать на всякий случай, «чтобы были», вы не лабораторную в институте делаете.
Делегирование, фабрики-шмабрики тоже в мусорку. Самое главное — это правило третьего раза: никаких лишних абстракций (функций, классов, интерфейсов), до тех пор пока вы не скопипастите какой-то кусок кода в третий раз. Выполнять это правило нужно абсолютно строго. Даже если вы точно знаете, что третий копипаст вам нужно будет сделать через месяц — ни в коем случае не создавайте абстракцию сейчас. Вот через месяц и создадите, когда понадобится. Это правило вообще нужно писать большими красными буквами на каждой странице каждой книги по паттернам, прости Господи, проектирования.
Нормальная функция должна занимать 10-30 строк в идеале; ну хотя бы 5. Нет, ну бывают конечно функции для «синтаксического сахара», но речь не о них. Человеку банально удобно работать с функцией на одной странице, когда она вся перед глазами и не надо никуда прыгать. Странично-слайдовое мышление, семь объектов и всё такое. Никто не убьет котенка, если вы залезете в соседний класс и вызовете его функции напрямую, без делегирования и подъема десятка интерфейсов, если того требует логика вашей программы. И если класс чего-то вроде «документ» или «главное окно» имеет 300 или даже 500 членов — совершенно ничего плохого в этом нет, это действительно год-класс для вашего приложения, который так или иначе отвечает за всё.
Да, по сегодняшним меркам подобный код, если мягко, «немодный» и даже «попахивает говнокодом», но это всё понты и шелуха. Если её отбросить, то код получается очень простым и понятным, его банально в три раза меньше, и главное он пишется очень быстро. Программист должен решать задачи, а не создавать абстракции.
1) Нормализируем гистограмму по каналам
2) Делаем High-Pass
3) Если изображение получилось малоконтрастным — нормализируем еще раз
4) Выбеляем светлое, зачерняем черное.
Человеку «на глаз» это сделать легко. А для автоматики нужно будет «натренировать» алгоритм (подобрать оптимальные коэффициенты), или предоставить, опять же, несколько вариантов на выбор пользователю.
1. В университетах отдаётся предпочтение теоретическим курсам за счёт урезания практической подготовки, в результате чего выпускники совершенно не готовы к профессиональной деятельности, причём чем приестижнее университет, тем более оторваны выпускники от реальности.
2. В этом есть и положительные стороны, т.к. благодаря такому подходу в голову студентам попадают таки-хорошие вещи типа Схемы и Питона. На этом положительные стороны заканчиваются.
3. От студентов можно добиться некоего подобия продуктивной работы путём жёсткого внешнего контроля через промежуточные дедлайны.
4. «невероятно, но факт» — опытные профессионалы качественно от студентов в этом плане не отличается — тоже просрут все сроки, дай только им такую возможность.
Если уж я взялся комментировать статью, то стоит сказать, что при трезвом взгляде, статья ни о чём. Первый тезис «студенты ничего не умеют» избит и общеизвестен, остальные можно объединить в «программисты — разгильдяи». С такой точки зрения непонятно зачем писать «если студентам дать доллгосрочное задание, то они просрут все сроки», ведь в этом нет ничего удивительного, раз состоявшиеся профессионалы ведут себя, в принципе, так же.
Вначале Джоел говорит в таком тоне, будто противопоставляет неумение студентов работать по графику умению состоявшихся программистов это делать, но в конце всё смазывает упоминанием, что программисты так работают под влиянием менеджеров, а не от хорошей жизни. Это, разумеется, очень спорный вопрос и другие авторы имеют другие мнение, но подобное противоречие внутри одного коротенького эссе как минимум странно. Кроме того, тут Джоел противоречит и некоторым более ранним своим статьям.
В результате сей текст напоминает поток сознания в виде размышлений на тему несовершенства мира, в которых родилась истина «программисты — разгильдяи». Я это понял когда перевод был уже почти завершен, поэтому решил всё-же опубликовать, хотя особой ценности статья и не представляет.
пздц :(
Вспомнилось интервью с Рэем Бредбери:
— В 1950 году вы написали книгу, принёсшую вам всемирную славу, — сборник рассказов «Марсианские хроники». Там говорилось: уже к началу второго тысячелетия на Марсе будут поселения, целые города землян. Как вы думаете, почему этого в итоге так и не произошло?
— Меня часто про такое спрашивают, и я люблю фантазировать над ответами. Ответ сегодняшнего дня: потому что люди — идиоты. Они сделали кучу глупостей: придумывали костюмы для собак, должность рекламного менеджера и штуки вроде айфона, не получив взамен ничего, кроме кислого послевкусия. Человечеству дали возможность бороздить космос, но оно хочет заниматься потреблением — пить пиво и смотреть сериалы.
Защита дипломов. Сначала выходит первый студет и гордо показывает «свою уникальную разработку» — пустышку на Joomla, причём не стесняется даже вставлять содранные с сайта UML диаграммы. Каждый слайд красочный, сочный, полон эффектов и градиентов. Ещё бы! Основная часть времени на диплом заняла как раз та самая призентация. Комиссия радостно кивает головами. Красиво же.
Второй студент рассказывает про какую-то мегакрутую нейросеть, которая позволяет выполнить какие-то полезные задачи на реальном производстве (есть даже акт о внедрении). Проделана огромная работа, студент еле уложился в печатный объём. Однако, все слайды его презентации — куча «скучных» формул черным шрифтом на белом фоне. Собственно, «весёлые» нейросети в природе встречаются редко. Комиссия сидит с пасмурными лицами. Единственный вопрос: «Вы не могли сделать повеселее презентацию?».
Первый студент получил «5», второй — «4».
А ведь инфраструктурный монополист (а в современном мире почти все монополисты инфраструктурные, да и в прошлом неинфраструктурные монополии обычно были в форме картелей, что все-таки немного другое) обычно предлагает продукт, который очень трудно заменить (говоря экономическим языком — продукт с низкой эластичностью спроса по цене, у которого нет субститутов)! Представьте, что вдруг исчезнет РЖД или Микрософт, или, например, какой-то большой представитель телекомов… Но к Гуглу, как уже было сказано выше, это все не относится. А значит, если его признают монополией и начнут «давить», то всем будет глубоко плевать — проблемы Гугла волнуют только Гугла.
Любопытно, что Гугл все это прекрасно понимает и из кожи вон лезет, чтобы стать незаменимым. Но пока ничего из этого не получается. И его будущее как «империи» во многом зависит именно от того, сможет ли он таковым стать.
Подмена фактов. На последней WWDC эту возможность презентовал Скотт Форстолл и вот что он сказал по этому поводу: «and you even can use the volume up button now to click the photo». Всё.
Но в жизни мы часто руководствуемся другими стратегиями:
– достаём более крепкий кнут;
– меняем всадника;
– говорим себе: «мы и раньше скакали на дохлой лошади»;
– создаём рабочую группу для изучения дохлой лошади;
– посещаем разные места, чтобы посмотреть, как скачут на дохлых лошадях там;
– создаём отдел по оживлению дохлой лошади;
– устраиваем тренировки, чтобы научиться лучше скакать на дохлой лошади;
– проводим сравнительный анализ всевозможных дохлых лошадей;
– изменяем критерии, устанавливающие, что лошадь мертва;
– нанимаем на стороне людей, якобы умеющих скакать на дохлой лошади;
– внушаем себе, что ни одна лошадь не может быть настолько дохлой, чтобы на ней нельзя было скакать;
– проводим исследования, чтобы узнать, есть ли более хорошие или более дешёвые дохлые лошади;
– объясняем себе, что наша дохлая лошадь быстрее, лучше и дешевле, чем другие;
– создаем совет по качеству, чтобы найти применение дохлым лошадям;
– пересматриваем условия работы для дохлых лошадей;
– расширяем сферу применения дохлых лошадей;
– и, наконец: образуем особый отдел, в котором изучают потребности именно дохлых лошадей.
Если найдёте или знаете источник по реальным экономическим показателям СССР, типа, инфляции, монетарных индексов, внешнего торгового баланса то киньте ссылку.
А Сталин лично никого не расстреливал. Он был вирулентный параноик и сам всего жутко боялся. Он просто кастрировал всё население на сто лет вперёд. Заразил всех своим животным страхом.
Вся беда в том что надо бороться не с олигархами и чиновниками, а такими как ты, а вас 90%. Тех для кого свобода, честь, собственность, демократия важнее чем благосостояние чиновников, их очень мало. Остальные думают, что если у Путина всё в порядке то и им хорошо. С этим невозможно бороться. Это проклятие.
Во-первых, в этой статье опять допустили классическую ошибку по этой теме: смешали TDD и умение писать юнит-тесты. Это 2 абсолютно разных вещи: TDD — это техника записи тестов перед кодом, юнит-тесты — это юнит-тесты :) Поэтому прежде чем практиковать TDD, научитесь писать юнит-тесты и не пытайтесь делать это одновременно — потратите много усилий и вероятно будете разочарованы. Умение писать юнит-тесты — такой же навык, например, как работа с регулярными выражениями. Вначале тяжело, а потом разбираешься и привыкаешь.
По юнит-тестам: уже рекомендованный выше Ошроув (маст-рид) и более академический Мессарош (xunit test patterns).
По ТДД: обе книги Кента Бека «TDD в примерах» и XP, они обе в сети есть.
Еще по архитектуре рекомендую «Чистый код» Р. Мартина («дядя Боб»)
Во-вторых, написание тестов для legacy-приложений, т.е. тех где в архитектуру не была заложена тестируемость (и у которых обычно отсутствуют тесты) — одна из самых сложных задач, под силу только test-гуру. Об этом почему-то практически все забывают. Если вы только начинаете с тестами — не беритесь за это в одиночку, лучше пригласите наемного специалиста и выделите на это бюджет (деньги/время).
В-третьих, обязательно нужно разделять виды тестов: юнит-тесты (про которые везде пишут), интеграционные тесты и системные тесты (про вторые и третьи намного меньше).
Юнит — все знают, тестируется один класс без внешних зависимостей (файловая система, бд, сеть — это заменяется заглушками). Работают везде, очень быстры, покрывают максимум кода.
Интеграционные тесты — тестируется взаимодействие нескольких классов вместе, по характеристикам обратны юнит-тестам: обычно внешние системы не подменяются, нужна настройка окружения, выполняются намного дольше, покрывают только нужные куски кода.
Системные тесты — тестируют систему сверху донизу, являются выполняемым ТЗ заказчика. Похожие на интеграционные тесты, но затрагивают всю систему, поэтому обычно выполняются еще дольше, сюда также относится тесты UI, внешних сервисов и т.п.
Очень важно разделять тесты в разные папки по типам, иначе они перемешаются и сложности настройки и эксплуатации интегр. и системных тестов убьют желание у разработчиков запускать вообще что бы то ни было.
1. Тесты зависят не от архитектуры, а от требований заказчика. Если — архитектура поменялась, а требования нет — тесты нужно подстроить под новую архитектуру. В плане ТДД — тесты меняются до изменения кода, поэтому «изменение архитектуры» происходит одновременно с изменениями тестов. Смысл ТДД — тесты двигаются чуть впереди кода и все действие идет маленькими шажками.
2. Тестирование элементарных блоков — это юнит, все зависимости подменяются моками. На все их писать необязательно, если метод очень простой (например, обычный геттер/сеттер), то только время убьете. Или у вас есть функция которая выполняет запрос к базе, типа такой:
function getClients($id) { return $this->db->query("SELECT * FROM clients WHERE id = $id"); }смысла писать на нее юнит-тест нет, а вот интеграционный — стоит.
Написание тестов до основного кода очень сильно влияет на конечную архитектуру приложения, она сама начинает делиться на слои, что в итоге дает более удобную и гибкую архитектуру.
Основное правило: если вам тяжело писать тест — меняйте архитектуру.
Пишите тесты и все у вас получится :)