![](https://webcf.waybackmachine.org/web/20221006115921im_/https://habrastorage.org/getpro/habr/upload_files/0b9/f6b/8e1/0b9f6b8e13a581c71749ee321abf8a8f.png)
.NET Multi-platform App UI – фреймворк, который пишут профессионалы. Тем не менее, код некоторых его функций выглядит так, будто разработчики забыли о последствиях разыменования нулевых ссылок.
Код, за который должно быть стыдно
.NET Multi-platform App UI – фреймворк, который пишут профессионалы. Тем не менее, код некоторых его функций выглядит так, будто разработчики забыли о последствиях разыменования нулевых ссылок.
В порыве альтруизма зашел на SO и наткнулся на очередной вопрос про создание переменных с динамическими именами. Вопросы про динамические переменные всплывют на SO довольно часто. На все подобные вопросы я отвечаю стандартно, используйте массив. Но в данном вопросе в переменные предлагалось переделать массив. И тут у меня бомбануло...
Давайте проведём исследование некоторых взаимосвязей функций, объектов, генераторов и корутин в Python.
На уровне теории, каждая из этих концепций очень сильно отличается от других; но динамическая природа языка позволяет им заменять друг друга на практике.
Предупреждаю: мы рассмотрим рабочие, но очень странные примеры кода; я не советую вам применять их в реальных проектах!
Всем привет! Решил на выходных продолжить писать свой домашний проект и наступила пора реализовать платформозависимый код. Самым простым вариантом было бы описать классы в *.h файле, а в зависимости от платформы, Закрытые поля засунуть под #define. При этом, саму реализацию по конкретным платформам разнести по *.cpp файлам и включать их в компиляцию в зависимости от текущей платформы. Но... мне не нравится как выглядит описание класса с #define, поэтому я решил убрать препроцессор и оставить в описании класса только интерфейс. И да, я не пользовался абстрактными классами и pimpl, всё еще хуже :-)
Авторы анализатора PVS-Studio предлагают вам проверить свою внимательность и развлечься. Попробуйте быстро отыскать баг в фрагменте исходного кода и ткнуть в него мышкой.
У каждого клиента – свои предпочтения. Не только в выборе автомобиля, блюда на обед или корпоративной информационной системы. Клиенты любят выбирать программистов.
Ну, что программисты разные – ежу понятно. Считается, что клиенты предпочитают профессионалов. Мы тоже так думали, и искренне стремились сделать каждого своего программиста этим самым профессионалом.
Однако, несколько клиентов, ставя нам задачи, упорно твердили: пусть программирует Серёжа. Хотя Серёжа – лютейший говнокодер, объект всеобщей жалости и главный поставщик материалов для конференций на тему «Как не надо программировать».
Приветствую всех программистов, а также сочувствующих. Кто из нас хотя бы раз в жизни не оставлял комментарии в коде? Был ли это ваш код, а может, чужой? Что за комментарии вы написали: полезные или не очень? А может, они были забавные, чтобы порадовать коллег или тимлида на следующем ревью? Давайте попробуем немного порассуждать и дать ответы на эти вопросы в формате небольшой заметки. Постараемся понять, что движет людьми, комментирующими свою программу. Упор сделаем на нестандартные, весёлые комментарии. У нас припасено для вас несколько отличных примеров. Поехали.
Не знаю, как у вас, в большом мире программирования, а у нас, в 1С, очень распространён подход «что вижу, то и программирую». Есть более удобоваримое название: «программирование от данных». Однако, чаще всего это называют говнокод. Хотя, тут я не согласен – до говнокода ещё надо немного подтянуть.
Обычно, необходимость в программировании от данных возникает под давлением ряда обстоятельств. Например, «надо срочно» или «вотпрямщас» (процентов 90 задач в 1С). Также случается «нечего там смотреть и анализировать, денег только содрать хотите» (те же 90%, пожалуй). Сверху накладывается «да точно ничего не поменяется через 10 лет» (а чего ему меняться, 90%!). Увы и ах, пересекаем три по девяносто, и получаем решающий фактор: 90% программистов 1С по-другому просто не умеют.
Поглядим на несколько примеров и их отложенных последствий.
Привет! Хотелось бы поделится своими впечатлениями о проведении одного из самых популярных технических соревнований в России и проблемами применения классического олимпиадного подхода к современным направлениям.
Disclaimer: пост пятничный, всерьёз не принимать.
Хронологически всё началось с Wordle. Про эту внезапно популярную игру говорили из каждого утюга, делались ролики на youtube, писались боты (а потом из каждого утюга и youtube рассказывали про этих ботов). Даже на Хабре появилось несколько статей на тему. Я тоже сыграл несколько раз.
В какой-то скучный выходной я не выдержал и захотел уже найти оптимальное слово, с которого надо начинать игру. Оптимальное — значит максимально уменьшающее пространство поиска, после которого в среднем останется как можно меньше слов, подходящих под ответ. Про саму программу я писать особо не буду, там все довольно просто, перебирается в лоб, код одноразовый, пишется минут за 10-15, считает секунд 15-20. Нашёл roate, потом оказалось, что можно было просто нагуглить.
Потом решил найти два стартовых слова, это уже считалось подольше, нашло пару carse + doilt, после которой в среднем останется всего четыре слова. И тут Остапа понесло.
Эти слова — оптимальные в среднем. А какие слова будут лучшими даже в самом худшем случае? Чтоб не тянуть интригу — это serai и пара tired + loans. Даже в самом худшем случае, какое бы слово не было бы загадано, после tired loans гарантировано останется не более 16 слов. Это результат для самых отъявленных пессимистов, которые всегда ожидают самого худшего.
Эти программы как перебирают — для каждого возможного слова из множества отгадок (или для каждой пары) перебирают все возможные загаданные слова и считают сколько подходящих слов должно остаться после ответа игры. И считают среднее или берут максимум. Но ведь кроме среднего реалиста и крайнего пессимиста могут быть и всякие промежуточные варианты. Можно ли как-то этот расчет обобщить?
Юмористический детектив о том, как нам подсунули свинью котлеты. Он не то что основан на реальных событиях, - это их подробное описание, без доли вымысла. Только отметок времени нет, для большей детализации. Но могу сказать, что на всё про всё ушло часа 3.
Вероятно, заголовок сбивает с толку, может показаться что это какой-то кликбейт. Но так вы сможете себе лучше представить мои эмоции, когда у меня спросили: «А откуда у нас в проекте котлеты?»
Понятное дело, что проект бы вряд ли от этого погиб, но, когда непонятные ошибки выпрыгивают накануне приёмо-сдаточных испытаний – относишься к ним соответственно. Да и как посмотреть в глаза заказчику, когда у тебя «котлеты»?!
Что будет, если к Perfmon применить быстрое преобразование Фурье? Или функцию корреляции? Получится #черте_что!
Я пишу статьи, посвященные написанию качественного кода и про поиск ошибок с помощью инструментов статического анализа. Однообразие наскучивает, хочется пошалить. А давайте все вместе напишем статью "100 вредных советов для С++ программиста". Я начну, а вы подхватите.
У Вас никогда не возникало желание добавить в код сладенькую засушенную изюминку в виде олдскульных бип-мелодий? Или играть музыку щёлкая клавиши на своём ПК с этим самым "ламповым" звучанием PC Speaker? Вот и у меня возникло.
Есть решение: Console.Beep воспроизводит звуки через PC Speaker (в связи с отсутствием системного драйвера начиная с Win 7 кзвук перенаправляется на звуковое устройство по умолчанию, по собственным наблюдениям на семёрке работает отвратно, зато на десятке вполне приемлемо, но возможно дело не только в операционной системе). Стоит уточнить что поддержка перегрузки Console.Beep(Int32, Int32) заявлена только для систем семейства MS Windows.
Для пауз нет ничего проще чем Thread.Sleep.
Всё что нам нужно - это using System и using System.Threading.
И на первой же мелодии я понял как это неудобно - записывать ноты в виде частоты и колличества миллисекунд. Вот собственно как это работает обычно...
В целях повышения доверия к электронным выборам и повышения прозрачности способа подсчета электронных голосов, предлага...
Всем привет!
В этой статье я расскажу, как я автоматически генерировал 42 стикера для Телеграма на основе изображений из интернет-магазина плакатов. На сайте продаются плакаты с разными забавными надписями, но соответствующих стикеров в Телеграме нет. Попробуем сделать сами. Единственная проблема состоит в следующем: чтобы сделать один стикер, нужно скачать фотографию плаката с сайта, отделить надпись от фона в фотошопе и сохранить в нужном разрешении, чтобы она соответствовала требованиям телеграма к стикерам. Поскольку изображений 42, это муторное и трудоемкое занятие.
Представьте, что вы директор небольшой средней школы, который хочет нанять новых учителей. Поскольку у вас в штате их должно быть не более 20, вы должны убедиться, что каждый учитель, которого вы нанимаете, сможет преподавать в любом классе. Усложним пример. Недавно уволилась одна из лучших учителей с более чем 15-ти летним стажем, и которая была наставником для многих более молодых сотрудников. Кем вы сможете её заменить?
После некоторых раздумий, вы создаёте, как вам кажется, творческий подход к интервьюированию. Когда кандидат придёт на интервью, вы попросите его провести урок, взятый из учебной программы средней школы. Поскольку вы хотите убедиться в том, что кандидат хорошо подготовлен, то вы не скажете ему какой урок он должен будет преподать. Если он справляется с таким заданием, то вы делаете вывод, что он с лёгкостью сможет провести любой урок, так как он хорошо себя проявил со случайно выбранной темой.
Вы размещаете объявление о найме и, через некоторое время, несколько интересных кандидатов подают заявки. Однако, протестировать свой новый подход вы планируете на учителе, которого рекомендовал один из ваших сотрудников, который работал с ней в прошлом, как классного специалиста. Вы не верите в своё счастье, что она вообще согласилась, и думаете, что она будет идеальным подопытным кроликом в вашем эксперименте. Вы связываетесь с ней, чтобы назначить день собеседования и рассказываете её о своём новом подходе, чтобы дать ей возможность подготовиться.
Наконец, наступает день интервью и ваш кандидат появляется в школе. Вы замечаете, что она немного нервничает, что странно, потому что она опытный кандидат и её резюме безупречно. Вы решаете не думать об этом и проводите её в один из ваших классов, чтобы начать собеседование. “Мне бы хотелось, чтобы вы преподали мне урок по теории чисел”. В этот момент её лицо помрачнело. Дело в том, что она не преподавала в 8-м классе вот уже более чем 10 лет. Но вы об этом не были осведомлены. Как профессионал, она пошла к доске и начала урок. Она рассказывает о множителях чисел и о том, как определить делится ли число на 2, 5 и 10. Но видно, как её трудно. Вы просите её рассказать о GСF и LCM, но она просит уточнить, что означают эти аббревиатуры. Вы расцениваете это как дурной знак и объясняете, что имели в виду “наибольший общий делитель” и “наименьшее общее кратное”. В этот момент вы замечаете, что её уверенность в себе поколебалась и чувствуете раздражение в её голосе.
Это продолжение статьи Локализация своих скриптов на BASH. В ней мы используя массивы и косвенные ссылки, научились добавлять в свои скрипты дополнительные языки и переключаться между ними.
В этой статье составим список встроенных языков и зададим выбор языка через меню, построив для этого многоуровневое меню. Чтобы статья не превратилась в один большой кусок кода с описанием каждой строчки, сам код с подробными комментариями я выложу ниже, а здесь затрону только несколько основных моментов.
Создание меню на BASH — задача сама по себе не сложная: "case тебе в руки и echo в спину". Решая её в очередной раз, мне захотелось добавить возможность отображать текст на других языках. Осталось решить, как сделать сам процесс локализации меню более удобным. Если оно большое, то решение "в лоб" превратит его в громоздкую копипасту. Здесь я хотел бы поделиться тем, как решил эту проблему для себя. Надеюсь, для кого то это будет небезынтересным.
Чтобы статья не вылилась в скучную простыню с излишком кода, решил разбить её на две части. В первой рассмотрим создание и добавление дополнительных языков. Во второй — создание многоуровнего меню и сохранение настроек
Я вполне понимаю и принимаю, что существуют и другие языки программирования. Как когда-то кто-то сказал здесь на Хабре — если при написании скрипта на BASH возникает необходимость хоть в одной функции, то лучше взять нормальный язык. Я с этим согласен, но иногда, как говорится, хочется, потому что хочется.
Мне не хотелось бы разбивать скрипт на несколько частей и хранить локализацию в отдельных файлах. Скрипт тем и удобен, что его проще использовать одним файлом. Поэтому тексты будем хранить в массивах.
Реализация будет состоять из:
Теперь рассмотрим подробнее