Типичный программист
Диагональная ориентация как идеал расположения экрана
Свободное вращение нашей планеты происходит с наклонением. Причины этому заложены давно. Вероятно, около 4,5 миллиарда лет назад Земля столкнулась с планетой Тейя. Так у нашей планеты появились спутник Луна и наклон орбиты в 22,44 °.
Поскольку Земля вращается вокруг своей оси с наклонением, это приводит к неравномерности распределения излучения Солнца. Говоря проще, именно из-за наклонения планеты мы испытываем смену времён года.
Если наклонение орбиты важно для жизни на Земле, то нужно ли применить наклонение в 23,44 ° для ориентации монитора?
Разработчик программного обеспечения наивно захочет ответить, что ему лучше подходит портретная ориентация: так легче читать страницы документации. С другой стороны, при более тщательном рассмотрении окажется, что лучшая ориентация дисплея — диагональная: так на экране уместятся даже самые длинные названия классов Java.
Выяснить пользу диагональной ориентации попыталась некто xssfox. Для этого она задействовала различные конфигурации Xorg.
Ынтырпрайзная Windows и прочие ширпотребные операционки уровня macOS не имеют поддержки диагональной ориентации дисплея. Достичь подобного получается только в Linux.
Максимальную эффективность использования пространства xssfox достигла при наклоне в 22 °. Однако xssfox никак не попыталась объяснить конкретную причину, почему это полученное эмпирическим путём значение так похоже на угол наклона оси вращения Земли.
А в остальном размышления логичны. Именно при наклоне в 22 ° на мониторе с разрешением сторон 21:9 получится разместить максимальную длину текстовых данных. С диагональной ориентацией больше не придётся беспокоиться об ограничении в 80 символов на строку.
Приведён лишь один недостаток: при таком наклоне монитора веб-камера норовит съехать вбок.
Работа была проделана неплохая. Как выяснила xssfox, Xorg принимает наклон в виде конфигурации xrandr --output HDMI-3 --transform, за чем должны следовать параметры вида cos(x),-sin(x),shift_left,sin(x),cos(x),shift_up,0,0,1, где x — угол наклона монитора, shift_left и shift_up — сдвиг картинки по осям X и Y.
Если, к примеру, речь идёт про наклон в 23,44 °, нужно задать параметры xrandr --output HDMI-1 --transform 0.91748,-0.39779,0,0.39779,0.91748,0,0,0,1. Сформировать параметры Xorg для работы с диагональной ориентацией поможет калькулятор на странице на сайте xssfox.
Любые другие эксперименты с диагональной ориентацией дисплея имеют малую популярность. К сожалению, это лишь слабо исследованные концепты.
Явные (как составленное по первым буквам абзацев сообщение) или нет, но попытки применить силу диагонали имеют право на жизнь.
Источник
Почему код не работает?
// го патчи в комменты
using System.Net;
namespace smile {
/// <summary>
/// Тестовый анекдот
/// </summary>
/// <remarks>
/// Ctrl+A, Ctrl+C, Ctrl+T, Ctrl+V или Alt+F4
/// </remarks>
/// <param name="PikabuPost">Ссылка на пост Пикабу.</param>
/// <param name="cancellationToken">Отмена операции.</param>
/// <returns>Фидбек <see cref="Like"/></returns>
public class AnekdotController : ControllerBase {
public async Task<IActionResult> GetAnekdot(Guid PikabuPost, CancellationToken cancellationToken)
{
Content($"— Сири, почему у меня не клеится с женщинами?\n— Я Алиса.");
}
}
}
Ponyscript — язык программирования пони
Ponyscript - это высокоуровневый язык программирования, вдохновленный популярным телесериалом "Friendship is magic".
Особенности:
Дружелюбный синтаксис: Ponyscript предлагает чистый и интуитивно понятный синтаксис, делая программирование более приятным и эффективным.
Компиляция в C++: Концепции Ponyscript компилируются в оптимизированный код на C++, обеспечивая высокую производительность и эффективность выполнения.
Простота использования: Благодаря простому и понятному синтаксису Ponyscript делает разработку программного обеспечения более эффективной и приятной.
int magic(int argc, char *argv[])
{
string a = "Hello Equestria";
neighln(a);
}
Больше информации вы можете прочесть в репозитории github
Найм в IT:
Ответ на пост «"Программисты не умеют программировать"»
В этом отношении мне в своё время понравилась программа для создания гильошей от фирмы-разработчика "CERBER". Одна из первых версий программы была написана на машинных кодах и весила меньше одного (!) мегабайта. Естественно, что декомпилировать и взломать её так никто и не смог, а бесплатная версия сохраняла готовые гильоши только в формате *.BMP.
Она, вроде как, существует и до сих пор, но пошла по пути наименьшего сопротивления, разрослась аж до 125 мегабайт в архиве, и мне таки кажется, что ломаную версию можно найти.
Для ЛЛ, гильош — это защитный элемент из кривых линий на ценных бумагах и денежных знаках.
Говорят, если гуманитарий пройдет это головоломку до конца, он может считать себя технарем
А еще получит ачивку в профиль. Рискнете?
Ответ на пост «"Программисты не умеют программировать"»
А ведь было же золотое время, когда большие циклы оптимизировали по времени, считая сумму тактов на цикл. И количество байт (не мб!) в программах минимизировали. Но потом пришли языки высокого уровня с кучей неоптимизированных библиотек.
Как то загорелся сделать программу для составления частотного словаря на Паскале. Для него понадобилась подпрограмма сортировки, которая должна была вызываться миллионы тысячи раз. Поэтому написал "пузырёк" на ассемблере. Когда сделал, стал искать аналоги в интернете. Нашёл одну распиаренную, которая на словаре Брокгауза и Евфрона (22мб) после получаса работы ушла в себя... Моя обрабатывала этот файл около 2-3 минут(*). Связался с автором, он рассказал, что написал программу за какой-то грант. А на вопрос, какой алгоритм сортировки использовал, ответил: "А хрен его знает? Взял какую-то готовую библиотеку и использовал модуль сортировки..."
(*) Сейчас на новом железе - 22сек.
*** 1 BROK_EFR.TXW (23270 kb)
Total words in Source: 3250130
sorting...
After sorting: 20,499 sec
After FRQ-counting: 21,887 sec
SortType=0 (alphabetical)
After sort of Destination: 21,887 sec
Total words in Destination: 282033
Total time: 21,965 sec
Average Speed: 1059 kb/sec