Автор: Владимир Герасименко

В продолжение темы про торговлю ядерными технологиями Абдул Кадыр Ханом и получение Пакистаном доступа к ним. Напомню основные моменты: В 1971 году в результате вмешательства Индии в Бангладешское восстание Пакистан теряет огромные территории (нынешний Бангладеш) и перед страной маячит угроза полного поражения в грядущем противостоянии. Срочно нужен был выход в виде собственного ядерного арсенала. Эта же мысль засела в голове молодого, амбициозного и талантливого "экспата" в голландском Делфте - Абдул Кадыр-Хана. Он как раз получил профильное образование вкупе с гражданством и устроился работать в FDO – дочку франко-германского концерна URENCO, конструировавшего и производившего оборудование для атомной отрасли Европы. В итоге 30-летней деятельности Хану удалось переправить на родину необходимую документацию для создания пакистанской Бомбы, но с производственными мощностями не заладилось - и тут на сцену выходит наш сегодняшний герой - швейцарец Фридрих Тиннер, с которым Хан немало контактировал ещё во время работы в FDO. 

Фридрих, как оказалось, держал в руках все нити поставок оборудования для проектов Хана. И только в 1999 году ЦРУ, пытаясь понять откуда у Ирана технологии для обогащения урана, случайно по наводке немцев вышли на Тиннера и его сыновей. Завербовав их, американцы получили просто вал информации, который их обескуражил.

Краткая история эволюции: челюстная часть черепа уменьшалась, а зубы не пропадали. Теперь образовалась пара лишних, которые только мешают. 

Зубы реально проблемные:

1. Прорезываются долго и мучительно.
2. Чаще всего растут не в нужную сторону и жевать ими не получается.
3. Нередко сдвигают зубной ряд и вызывают аномалии прикуса уже в юношеском возрасте.
4. Первые разрушаются от кариеса и являются источником риска тяжёлых гнойных заболеваний.

В общем, у нас есть третий моляр, он же жевательный «зуб мудрости». Но:

1. Жевать вы им не можете.
2. Протез на него не поставите.
3. Нормально запломбировать каналы в нём сложно или невозможно.
4. От кариеса он разрушится первым из-за сложной гигиены и принесёт радость и счастье во всю ротовую полость. 
5. При первом удобном случае сдвинет вам пропеллером весь зубной ряд.
6. Может стать чудесной причиной флегмоны, из-за которой, возможно, придётся делать разрезы скальпелем от уха до уха, чтобы спасти жизнь.

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

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

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

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

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

Всем привет!

Сегодня расскажем о сравнительно новой для нас теме — про перевод приложения с Oracle на Postgres Pro (далее в тексте везде сокращу до PG). В общем смысле тема не столь уж нова — многие компании этим также занимаются или даже уже прошли этот путь. Так, например, на ежегодной конференции pgConf всегда есть несколько интересных докладов по этой теме (https://pgconf.ru/). Если говорить о формальностях, то мы реализуем инициативу согласно (Приказ Министерства связи «Об утверждении плана по импортозамещению программного обеспечения» от 01.02.2015 № 96). По факту — ещё и денег экономим, слезая с "лицензионной иглы". На эту тему можно отдельную статью написать, а в этой речь пойдёт о программной стороне вопроса. Кому интересно, добро пожаловать под кат.

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

Oracle, придя на рынок облачных сервисов, активно привлекает новых клиентов. И одним из инструментов такого привлечения являются Always Free сервисы - зарегистрировавшийся клиент может пользоваться каким-то достаточно ограниченным набором ресурсов, как это следует из названия, бесплатно и неограниченно во времени. В список этих ресурсов входит два compute инстанса (каждый 2 ядра, 1GB RAM, 45GB HDD), которые можно использовать подо что угодно, но в нашем случае мы можем построить на них полностью бесплатный OpenVPN-сервер, буквально не умея практически ничего, кроме тыкания в кнопку Next. Чем мы и займемся.

Всем доброго времени суток. Сегодня хочу рассказать максимум о регулярных выражениях: что они из себя представляют, как их писать, для чего нужны и т.д.

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

Рассмотрим старые и новые подходы к решению проблем стабильности/волатильности криптовалют.

* Традиционные USDT, etc

* Ampleforth

* Двухконтурная BAY

Привет, менеджер!

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

Совсем немного введения

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

Как правило, до начала процесса разработки подготавливается описание основных, самых важных компонентов и достаточно поверхностно, некоторые детали могут быть описаны подробнее, при необходимости. Детализация требований происходит параллельно с процессом программирования и фиксируется, обычно, в ТЗ, а также в виде задач для команды. Такой подход позволяет на этапе инициации проекта достаточно быстро подготовить информацию по проекту, которую можно использовать в оценке проекта, а также дает большую гибкость в реализации проекта, так как требования имеют свойство меняться в процессе (закладываем на это время в оценке).

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

Для полноценного проектирования и детализации требований продукта необходимо подготовить следующее...

Павел Селиванов почти 3 года прожил на Балканах. Сначала в Черногории, потом в Сербии. Мы побеседовали с Павлом, и он рассказал о жизни в Европе, черногорских квартирах и сербской кухне, а еще почему баня с пельменями — это вам не СПА с равиоли.

Как по мне достаточно важная, хотя и холиварная тема. Думаю каждый из нас задавал себе вопросы: "можно не дублировать проверки?", "а не усложняю ли я?", "да как же это сделать нормально?!".

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

Текст рассчитан не на новичков, потому нормально, если по ходу чтения какие-то понятия будут вам неизвестны, я постарался коротко раскрыть их здесь, а также указал ссылки на посты в моём телеграм канале Beer::PHP ​, которые могут чуть подробнее раскрыть то или иное понятие.

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

Тимлидами редко рождаются, чаще — становятся. Самый частый пример, который я видел — тимлидом назначают самого ответственного разработчика из команды. Наделить ответственного человека еще большей ответственностью — сильное и эффективное решение, правда же? 

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

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

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

В этом году сотрудники оценили CloudPayments на Хабр Карьере на 4,8 из пяти, и это обеспечило компании четвертое место в нашем Рейтинге ИТ-работодателей среди компаний со штатом до 1000 человек.

Я уже довольно давно разрабатываю навыки для Яндекс.Алисы, но пока не создал ни одного популярного. Недавно мне стало интересно: а какие навыки становятся самыми популярными, и кто те люди, которые их создают? Чтобы ответить на этот вопрос, я проанализировал каталог Алисы и опросил 20 разработчиков, чьи навыки набрали наибольшее количество оценок "пять". Похоже, что к их советам стоит прислушаться.

Привет. Меня зовут Владимир, я работаю в «AliExpress Россия» специалистом по локализации.

AliExpress известен своими странными переводами. Сколько шуток было на эту тему, даже от нас самих. И сторонний наблюдатель восклицает: «Ну сделайте уже нормально!»; продвинутый технарь ухмыляется: «Не могут нормальный Гугл Транслейт прикрутить»; а профессионалы из области машинного перевода наперебой советуют «кастомизированный движок» или MTPE. Все они и правы, и неправы одновременно.