Роскомнадзор — пособники террористов?

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

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

А после следующего ещё что-нибудь запретят. Ведь теракт это страшно. Настолько страшно, что из страха надо запретить.

Сопровождение БД Oracle

Вы можете заказать услуги по сопровождению систем на БД Oracle (в части БД) в соответствии со стандартом ГОСТ Р ИСО/МЭК 14764-2002.

Для получения условий пишите запрос коммерческого предложения в комментариях к посту (комментарии будут видны только автору сайта).

Наши клиенты:

Проверить http ресурс

Бывает, что по тем или иным причинам сайт перестаёт работать. Чтобы иметь возможность провести восстановительные работы в автоматическом режим, полезно иметь возможность проверить, свалился уже сайт или ещё нет.

Проверить, работает ли ссылка или нет, можно с помощью простенького консольного приложения Url_iS_brokeN ( Url_iS_brokeN Проверка недоступности ссылки )

Удалить BOM

Нередко возникает ситуация, когда надо взять и удалить BOM из кучи файлов. И далеко не всегда есть нормальная операционка под рукой с sed и awk. Как быть? В этом случае поможет DeBOMinator — простенькое средство для удаления BOM’ов из всех файлов.

DeBOMinator — как удалить BOM из кучи файлов

Постоянство — признак мастерства

Очередной госпроект с треском провалился.

http://echo.msk.ru/blog/teseyinfo/1911844-echo/

И опять из-за АТ Консалтинга. Из-за кого бы ещё? Мне редко встречались проекты в последние 10 лет, в неудачах которых не был бы виноват АТ Консалтинг.

Не понимаю, почему руководство компании  лезет во все дыры, где у него есть хорошие друзья, которые его приглашают. И не понимаю, как друзья могут остаться хорошими после этого.

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

Неужели руководству компании мало денег, которые получает от Вымпелкома? Или оно верит, что можно вот так вот взять, кинуть проверенного узбека на лыжах на очередную вражескую амбразуру и получить результат, сравнимый с тем, который получают профессионалы?

А не такой вот, стандартный, скажем так, результат….

при миграции данных региона ни один объект из 2 млн. в пилотном регионе не мигрировал безошибочно

Не понимаю я этого. Зачем губить свою собственную страну, убивая в ней все возможные точки роста и забирая, за счёт связей, проекты, которые всё равно сделать не можете? Это же не Гондурас какой, это ваша страна.

Как написать хорошее ТЗ

  1. В ТЗ не должно быть говнокода. В том числе, говнокода, написанного на русском языке, или любым псевдокодом. То есть, в ТЗ не должно быть слов «возьмём», «сложим», «вычтем», «найдём» и любых аналогов таких слов. Почему? Да потому что читабельность говнокода в ТЗ меньше читабельности кода в коде. То есть, ТЗ выполненное в виде говнокода нечитаемо. Но это полбеды. Для того, чтобы такое ТЗ реализовать, надо понять что требуется сделать, выведя это из говнокода, описывающего, как это предлагается сделать. То есть, провести работу по анализу ТЗ, что можно сделать, если это делается один раз, но…. После кодировнаия такого говноТЗ начнётся этап тестирования, исправления ошибок и работу по анализу и выводу требований из фантазийной реализации придётся проводить заново. Вместо слов «сложим» должна быть «сумма», вместо слов «найдём» условия поиска. ТЗ должно быть декларативным, описывающим требование в статике, а не итеративным, описывающим шаги алгоритма. И это важно не только из-за читаемости… Чем раньше будет выявлена ошибка, тем цена ошибки меньше. ТЗ, написанное на русском языке, в бизнес-терминах, отлично верифицируется и понимается, то есть, в нём возможно найти ошибки на этапе чтения и исправить их, когда цена исправления минимальна. ТЗ, выполненное в виде говнокода верифицировать невозможно, следовательно цена ошибки в таком ТЗ всегда будет максимальной, как и трудоёмкость работы с таким документом.
  2. В ТЗ не должно быть чатика аналитиков. Ну реально никому неинтересно в этом мире, какие вопросы банку задавал аналитик, и что ему ответили. В ТЗ должен быть результат работы, а не поток сознания, который надо анализировать. ТЗ это документ с номерм версии, а не переписка.
  3. В ТЗ не должно быть всё свалено в кучу. Конце концов, задача в том и заключается, чтобы из моря известной информации (все всё знают по большому счёту) высветить островок информации нужной, которая относится к задаче. Любой мусор, промежуточные результаты, приложенные «за компанию», от которых можно избавиться недопустимы. Документ должен содержать свёртку информации из кучи, а не кучу всего, что удалось найти и что относится, тем или иным боком, к задаче.

Работа в BI Publisher

Столкнулся со странным желанием некоторых людей изучать Oracle BI Publisher. Собственно, это не рокет сайнс, там изучать особо нечего. Но раз есть спрос, то почему бы и не показать, что это такое……

В связи с этим, восстановил из архива древнюю-предревнюю, как сама жизнь, свою собственную статью по Oracle BI Publisher.

Ссылка на восстановленную статью: Памятка разработчика по BI Publisher

Собственно, кроме прочего, это пример того, как руководитель должен создавать информационное поле команды и доводить сведения до подчинённых.

Хотите понятных и прозрачных документов, обученной команды и результата в короткие сроки без рабских переработок?

Берите на работу правильных руководителей!

Позитивность спасает не всегда

Когда я учился в школе, на одном из занятий по ОБЖ наш класс отвели в тренировочную базу флота, заперли в комнате и через искуственную пробоину стали пускать воду, дабы мы получили опыт по заделыванию пробоины.

Вода шла под давлением 20 атмосфер и установить заплатку было не так-то просто. Пробоину мы заделали. Но тогда я понял одну вещь — когда корабль заливает вода под давлением 20 атмосфер, никакой позитив не спасает.

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

В ситуации, когда жизнь висит на волоске, любой самообман всегда приводит к поражению, как к поражению личному, так и к поражению всей команды, а ведь жизнь каждого в этой стране далеко не на толстом канате повешена.

Достаточно зимой на морозе оказаться в лесу только потому, что инспектору ГИБДД не понравилось крепление номера, и ты уже труп.

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

Тогда придёт понимание реальной жизни.

Хорошие программисты на внедрении вредят развитию ИТ отрасли

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

Да и вообще, в принципе, от программистов один вред, если подумать.

Чем больше народу выполняет разработку, тем более неожиданным получается результат

Почему? Потому что возникает соблазн вместо достижения цели делать внеплановые задачи типа добавления дополнительных триггеров, которые сами-по себе зло, и иных украшательств, которыми никто не будет пользоваться, но которые саппорт затруднят своим наличием, ибо их придётся учитывать.

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

А отсюда вывод: чтобы результат был нормальным, надо максимально сократить число задач и задействованных участников. Ибо не ошибается тот, кто ничего не делает!

А что значит сократить число участников? Это значит, в том числе, и сократить избыточные коммуникации, поделив области не послойно, подобно блинному пирогу с начинкой, а покусочно, подобно чизкейку в Шоколаднице, когда каждый получит максимально целый кусок общего пирога. Что значит кусок пирога максимально целый? Это значит, что он содержит в себе максимальное число признаков общего пирога. То есть, выполняется принцип подобия — что вверху, то и внизу, указанный ещё в знаменитой изумрудной скрижали.

Тогда сложность системы разработчиков снизится с N^2 (каждый связан с каждым) до N+1 и, следовательно, снизится и уровень непредсказуемости итогового результата.

Такой подход напоминает феодальную систему в разработке, и он, похоже, единственно верный.