Развитие происходит по спирали: когда-то люди не умели правильно индексировать, потом (в основном) научились, потом пришли noSQL и все снова забыли знание древних. Что вы будете делать, когда последние из старых DBA отплывут в Валинор?

Снова и снова и сталкиваюсь с полным набором антипаттернов индексирования. Я их перечислю, но! Для каждого антипаттерна есть исключение, когда именно это и стоит делать. Поэтому кликбейтно сформулированное правило верно в 95% случаях, но если вы хотите копнуть глубже, то прочитайте про исключения.

И в конце полезные скрипты для MSSQL, Postgres и MySQL.

Данная статья представляет собой набор рецептов по созданию WPF приложений. Поэтому скорее всего она будет интересна начинающим разработчикам. В материале описаны основные моменты использования таких пакетов как ReactiveUI, Material Design in XAML Toolkit, LiveChart2. Примеры кода приведены из реального приложения.

Приветствую, уважаемые хаброжители!

Так как занимаюсь переводом кода с MS SQL в Postgre SQL с начала 2019 года, то решил продолжить сравнение этих двух СУБД.

В прошлой публикации мы рассматривали отличия в быстродействии MS SQL и PostgreSQL для 1C.

Сегодня давайте сравним основные конструкции синтаксиса MS SQL и PostgreSQL для правильного чтения кода, а также для того, чтобы быстро изменить код из MS SQL для PostgreSQL или наоборот.

Начнем рассмотрение с сопоставления типов.

Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая старые файлы наткнулся на свои записи и решил все таки поделиться ими с Вами. Частое употребление ключевого слова к сожалению, неизбежно и не отделимо для целостности этого текста, прошу принимать или нет 'as is'. Итак...

Каждая карьера развивается от Жопы к Жопе, и никак иначе. Хочешь повышения - ищи Жопу и принимай, как говорят в Америке, "challenge". Если Вам предлагают возглавить новый проект, либо занять какую то должность, да что угодно - знайте, там Вас ждет Жопа. Иначе не предложили бы, а сами бы справились. Равно как и если Вы ожидаете избавиться от надоевшей Вам сейчас деятельности, надеясь вырваться из "этого ада" и заняться "чем то новеньким" - будьте готовы встретиться с Большой Жопой.

Суд в России дело долгое, но в Европе ещё дольше. Нашим судебным разбирательствам с ВТБ уже почти два года, и история ещё не закончилась. Полагаю, что до финала мы дойдём ещё через 1-2 года. Но возможно у ВТБ сейчас проснётся совесть, они публично признают, что были дико неправы, принесут извинения и пообещают, что больше никогда не будут ни так, ни как-либо иначе злоупотреблять правом и нагибать своих клиентов. Правда, фильм “Яхта, самолёт, девушка” посмотрели 13 миллионов человек, и никакой совести ни у кого не проснулось.

На сегодняшний момент мы прошли:

1. Первую инстанцию и проиграли.
2. Апелляцию — проиграли.
3. Кассация постановила дело пересмотреть.
4. Первая инстанция та же судья пересмотрела и опять вынесла решение в пользу ВТБ.
5. Апелляцию опять проиграли.
6. Кассацию выиграли и надеюсь поставили точку!

Ничто так не вызывает интерес у противоположного пола, как страстные разъяснения физики кротовых нор.

У каждого есть мечта; я хотел бы дожить до рассвета, но знаю, что мне осталось менее трёх часов. Будет ночь, но это неважно. Умирать просто. Для этого не нужен свет. Так тому и быть: я умру при свете звёзд.
— Виктор Гюго

Сюжетная линия одноименного музыкального альбома

Глядя на бескрайнюю россыпь звезд в ночном небе, почти любой человек хоть раз задавался вопросом: интересно, мы одни во вселенной? Тема контакта с внеземным разумом давно стала классической для научной фантастики. Многих авторов интересует именно момент первой встречи, тревожная новизна и неизвестность. Чем именно они будут отличаться от нас? Сможем ли мы вообще понять друг друга?

За долгие годы на эту тему было сказано, снято и написано, мягко говоря, немало. Иногда кажется, что тема «первого контакта» и вовсе исчерпала себя. Но раз за разом находятся авторы, которые находят свежий подход и удивляют своими идеями. Вот несколько тому примеров — от классики до современных книг. 

Шел 2021 год, русские хакеры продолжают переигрывать и уничтожать загнивающий Запад, вмешиваясь в выборы, ломая фейсбуки и пентагоны. Тем временем на Хабре выходят статьи о создании неубиваемых Kubernetes-кластеров, которые, по видимому, всех нас переживут. А кто-нибудь подумал о простых пацанах (пацанессах)??? Как быть обычному программисту, который хочет свой небольшой кластер и ламповый CI/CD с автодеплоем приложения, чтобы кенты с района не засмеяли?

Всем привет, меня зовут Алексей и я алкоголик разработчик на Python/Go в Домклик. Сегодня мы будем понижать порог входа в self-hosted Kubernetes и GitLab AutoDevops.

В последнее время использование протокола HTTPS для Web-ресурсов является обязательным требованиям ко всем более-менее большим Web-проектам. Эта технология основана на использовании так называемых сертификатов. Раньше за получение своего сертификата нужно было платить. Но сегодня появление таких сервисов, как Let's Encrypt сделало возможным получение сертификатов бесплатно. Таким образом, цена больше не служит оправданием отказа от использования HTTPS.

В самом простом случае сертификат позволяет установить защищённое соединение между клиентом и сервером. Но это далеко не всё, на что они способны. В частности, недавно я смотрел на Pluralsight курс Microservices Security. И там среди прочих упоминалась такая вещь, как Mutual Transport Layer Security. Она позволяет не только клиенту убедиться в том, что он общается именно с тем сервером, с которым хочет, но и сервер может узнать, что за клиент с ним общается.

Всё это накладывает на разработчиков необходимость знать способы работы с сертификатами. Именно поэтому я и решил написать эту статью. Я задумал её как место, куда можно обратиться за основными сведениями, если что-то забудешь. Не думаю, что специалисты найдут в ней что-то новое, но надеюсь, что она будет полезна новичкам и тем, кто захочет освежить свои знания в этом вопросе.

Данная статья содержит небольшое введение в JIT-компиляцию и .NET Core (отныне .NET 5, .NET 6 и так далее), а также несколько практических примеров ускорения запуска приложений на .NET. Данные советы могут быть полезны как для приложений, запускаемых на больших многоядерных x64 серверах, так и для приложений, запускаемых на ARM чипах с малым числом ядер. Например, подобные оптимизации используются в операционной системе Tizen, об этом далее.

Инструкция по диагностике проблем в работе баз данных в случае аварии.

Привет. У каждого на работе иногда случаются «чёрные» дни. Для меня такими днями являются аварии в работе сервисов, приводящие к недоступности систем для конечных пользователей. По счастью, такое происходит нечасто, но каждый такой случай заставляет меня долго рефлексировать над вопросами «что мы сделали не так».

После одной из аварий я поймал себя на мысли, что диагностика причины недоступности сервиса заняла слишком много времени. Инженеры, задействованные в разрешении инцидента, действовали не совсем скоординированно: проверяли одни и те же гипотезы и тратили время на изучение совсем уж «фантастических» вариантов. В квалификации ребят никакого сомнения у меня нет, поэтому в рамках рефлексии я списываю это на стрессовую ситуацию аварии.

Чтобы в следующий раз диагностика и устранение причин аварии происходили быстрее, мы совместно с DevOps-инженером Алексеем Поповым решили написать «план эвакуации при пожаре»: пошаговую инструкцию, которую можно было бы использовать для быстрого исследования инцидента.

Последняя проблема касалась работы базы данных и взаимодействия web-приложения с базой. Поэтому инструкция касается диагностики именно базы данных. Также хочу отметить, что эта схема — не истина в последней инстанции, а всего лишь наш опыт, перенесенный на «бумагу». Мы намеренно не стали включать слишком «экзотические» причины аварии, поскольку схема становится слишком громоздкой и нечитаемой.

Я буду признателен за комментарии и описания аналогичных проблем, которые происходили у вас.

Предисловие

Мой переход на F# в качестве излюбленного языка был слегка усеян препятствиями. Примерно через десять лет почти постоянного использования C# у меня пробудилось любопытство, когда я услышал об этом другом #-языке. Моя первая реакция была той, которую с тех пор видел у других C#-разработчиков — отрицание, — C# является хорошим языком, и мне с ним комфортно, так зачем тратить силы на изучение другого? Но любопытство осталось — и, по крайней мере, несколько раз выделил вечер, чтобы прочитать базовый вводный пост и попытаться написать каких-нибудь ката на F#. Это не прижилось, потому что я просто чувствовал себя потерянным и не мог воплотить свой опыт использования C# в ощущение даже отдаленного комфорта с F#. Достаточно легко опустить фигурные скобки, немного замяться, чтобы не забыть let вместо var — но как сделать то, что я хотел?

Тогда я этого не осознавал, но, на мой взгляд, наблюдал потенциальный недостаток в том, как F#-разработчики говорят, описывают и представляют свой язык внешнему миру. Существует обширная база материалов обо всех возможностях и функциональности F#: Algebraic Data Types, Exhaustive Matching, Type Inference и т.д. Есть много статей, посвященных тому, как решать широкий спектр задач с помощью F#. Но, как мне кажется, не хватает чего-то вроде следующего: некоторых указаний о том, как взять то, что вам уже удобно в C#, и перевести их на F#. Так что мне интересно, можем ли мы как-то закрыть этот недостаток.

Мы живем в удивительное время — каждый становится экспертом, прочитав пару статей из интернета. Есть, конечно, сферы жизни, в которых мы были экспертами всегда, еще задолго до появления всемирной сети. Например, футбол, хоккей, отношения и управление страной.

Но теперь мы дополнительно освоили и специальности, требующие специфических знаний. Например, медицина. Google в помощь — и вот мы поправляем врачей, сами ставим себе диагноз и назначаем лечение. И только когда совсем уже худо, когда петух непрерывно начинает клевать в то место, где спина теряет свое благородное название, мы бежим к врачу, которому приходится не только лечить запущенную болезнь, но и бороться с последствиями нашего интернет-лечения.

Подобная ситуация и с налогами. Интернет пестрит всевозможными советами, как и что делать во время налоговой проверки, очень часто прямо противоречащими друг другу.

Кто-то советует сразу включить видеокамеру и диктофон, кто-то предлагает выделить кабинет с чайником, СВЧ-печью и заполненным холодильником. Одни предлагают свести устное общение к минимуму, другие дают советы, как расположить к себе, в стиле «называйте чаще по имени», «делайте комплименты, но не льстите», «попросите совета на будущее». Одни советы слишком общие, другие излишне конкретизированные, а некоторые вообще опасны и могут привести к негативным и непредсказуемым последствиям.

Испытывая желание нести знания в массы и искренне переживая за налоговое здоровье наших сограждан, мы тщательно проанализировали имеющуюся информацию о проведении налоговых проверок, а также обобщили наш 10-летний опыт сопровождения налоговых проверок.

Наша задача — определить конкретные правила поведения, алгоритм действий налогоплательщика, результатом выполнения которых будет минимизация возможных доначислений.

Обратите внимание — именно минимизация, так как доначисления, конечно, будут. «Нулевые» проверки — это нонсенс. Ведь от эффективности проверок зависят показатели инспекции и, соответственно, премирование сотрудников. Поэтому доначисления будут, но то, в каком объеме и, самое главное, будут ли у вас основания их оспорить в суде, во многом зависит от качества ваших действий во время налоговой проверки.