Как-то я наткнулся на интересную тайм-ленту предполагаемых событий вселенной на википедии, но она была довольно скудной и без картинок, так что я залез в гугл и поискал «future time line», и первое, что увидел, — этот сайт. Мне очень понравилась эта статья и я решил перевести ее, заодно и вычитать ее получше.
Все, что здесь изложено — лишь предположения и теории, вполне возможно, что все или некоторые события будут не такими. Весь пост представлен в виде тайм-ленты от 10000 до 10¹⁰⁰ года, и содержит много интересных картинок и ссылок на вики, читать много и интересно.

---

10 000 – 15 000 Н.Э.

Гиперновая из звездной системы Эта Киля начинает воздействовать на наш регион Галактики

Эта Киля – одна из самых больших и нестабильных звезд в нашей Галактике. Ее температура настолько высока, что ее гравитация не в состоянии удерживать газ, утекающий с ее поверхности по сформированным потокам вверх, от нее. Она впервые была замечена в 1843 году, когда ее звездная величина (читай величина свечения) достигла -0.8, сделав ее второй по яркости звездой в ночном небе.
Она в дальнейшем утихла на какое-то время, и снова «засветила» в конце 1990-х. Эта флуктуация продолжается с периодичным вспыхиванием и затуханием, и будет продолжаться до тех пор, пока не случится неизбежное. Не в состоянии совладать с собственной массой и плотностью, она коллапсирует и, потом, превращается в одну из самых смертельных сил, известных в природе – в гиперновую.
На какое-то время, этот колоссальный взрыв освещает всю галактику. Это будет достаточно ярко, чтобы заметить в дневное время с Земли, в то время как ночью это сравнимо с полной луной.
Но гораздо больше вреда принесут убийственные струи гамма-излучения, выброшенные умирающей звездой. Они будут выброшены на таких высоких энергиях, что даже системы в тысячах световых лет от Эта Киля будут задеты. В результате, на многочисленных планетах в нашем регионе Галактики произойдет вымирание живых организмов в это время.

По следам поста о неудачах Роскосмоса и в одурении от количества топиков про Curiosity

Вчера я попробовал кое-что поискать по Хабру. Результат:
«Curiosity» — 17 топиков;
«Фобос-Грунт» — 4 топика.
«Радиоастрон» — 0 топиков.
(Я считал топики, явно посвященные сабжу.)

Печально это, господа гики. В том топике про Роскосмос была высказана мысль, что современной российской технической интеллингенции плевать на российские успехи — ей интересно только тыкать пальцем «а вот на Западе-то ооо!» и «просрали все полимеры, ворьё».

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

«Радиоастрон» — международный проект фундаментальных исследований космоса в радиодиапазоне. Для реализации этого проекта на околоземную орбиту 18 июля 2011 года был выведен «Спектр-Р» — космическая обсерватория, представляющая собой 10-метровый радиотелескоп, обращающийся вокруг Земли по сильно вытянутой эллиптической орбите (перигей — 10 000 км, апогей — 390 000 км, сравнимо с расстоянием до Луны).

Координатор проекта — Астрокосмический центр ФИАН, аппарат разработан НПО им. Лавочкина, выведен на орбиту с помощью ракеты-носителя Зенит-2 с разгонным блоком Фрегат-СБ (также разработан в НПО им. Лавочкина). Проект «Радиоастрон» — единственный запуск космического аппарата на высокую орбиту за весь 2011 год.

Озвучивал знакомый, я думал раньше не было русской озвучки.

Говорят, в Apple используют автоматическое внутривенное вливание шнапса.
Отсюда

Человеческой изобретательности нет предела.
На этот раз нашли способ запускать Windows 3.1 (а возможно и выше) на аппарате под управлением OS Android.



Система устанавливается оригинальная и полностью рабочая, единственный большой минус — довольно сложное управление.

И так для этого нам понадобится:

1. Аппарат с Android версии 2.2 или выше
2. Приложение aDosBox
3. Установочные файлы Windows
4. Свободное место на SD карте или в самом аппарате (20 мб (это проблема..))
5. Прямые руки

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

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

Всем привет.

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

Пост будет о том, как удалось обойти лимит на одну порцию, установленный в столовой.

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

Этот пост не ориентирован на кулхацкеров, поэтому если вы знаете, что using компилируется с конструкцией вызова Dispose для энумератора, что для работы оператора foreach не обязательно использовать интерфейсы, а достаточно иметь метод GetEnumerator, возвращающий энумератор корректной сигнатуры, что сам Enumerator — изменяемая (мутабельная) структура, что может стать причиной неожиданного бага… То просьба не заходить и не читать, сэкономьте свое время, не надо оставлять посты вроде «КГ\АМ», «боян», и «Капитаны отаке». Остальных прошу под кат.

Итак, вторая часть. Здесь я раскрою как получить информацию от пользователя, а так же о манипуляции этими данными. Тут можно затронуть вопрос, поднятый в комментариях к предыдущему посту — «А зачем это все нужно?». Примерами применения таких интерфейсов в 21-м веке являются различные аплаянсы на виртуальных машинах, которые реализуют отдельные сервисы. Чаще всего они представляют из себя минимальный дистрибутив Linux или набор загружаемое ядро + busybox. С помощью такого интерфейса можно реализовать некий фронтэнд для сервиса, позволяющий одним взглядом определить состояние основных узлов или выполнить некие операции в удобной для пользователя форме. Примером можно назвать подобные фронтэнды у VMware ESXi (vDirector, vCenter etc), Citrix Xen, которые сочетают как мощь web-интерфейса, так и TUI как резервного интерфейса и/или интерфейса настройки/диагностики. Переключаясь по десяткам машин можно одним взглядом увидеть, все ли в порядке или быстро узнать IP адрес, полностью заблокировав юзеру доступ к консоли, показывая ему только то, что ему достаточно знать (foolproof).

Периодически просматривая топики на хабре, постоянно ловлю себя на мысли, что ещё чуть-чуть и какой-нибудь нейроинтерфейс в ноутбуке станет реальностью. В работе постоянно натыкаюсь на то, что современные люди не очень понимают и любят простую командную строку. А читать мануалы им тем более лень.
Но в моей практике часто случается так, что нужна небольшая утилита, выполняющая одну или две функции. А где именно она будет выполняться — неизвестно. Это может быть Windows, это может быть исключительно терминальный линукс, загрузочная медия — что угодно. Я не программист, но иногда бывает нужно облегчить жизнь себе или другим. И желательно как можно более наглядно. Сначала я пробовал делать просто консольные утилиты. Собственно, с этого, наверное, начинают все. Но очень быстро оказалось, что средствами printf/sprintf/puts и прочими (а пишу я на С) не очень удобно форматировать текст, выводить какую-то информацию. Окно с постоянным «скроллингом» выглядит не очень красиво, и если информации много — абсолютно нечитаемо. Тогда я вспомнил про ncurses.

Несколько лет назад мы – авторы данного материала – изрядно покопавшись в патентах, дневниках и лекциях Н.Теслы (благо, образование позволяло) пришли к выводу, что пресловутая Башня Тесла по передаче энергии не «фейк», а вполне рабочая конструкция.

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

Этот материал не является строгой теорией (т.е. теорией, учитывающей все возможные аспекты работы Башни Теслы). Тем не менее, мы постарались достаточно полно осветить предлагаемую концепцию и привести адекватные численные оценки основных характеристик процесса. Так что, если Вам интересно разобраться в модели и поучаствовать в конструктивной дискуссии – приглашаем ознакомиться с материалами.

Как мы и обещали, мы начинаем серию постов о технологиях и техниках, которые используются в нашей компании. Начать бы мы хотели с внутреннего продукта, который называется OMPW — Oversun Media Players Wizard — помощник сопровождения пользователей. Эта система используется практически всеми отделами нашей компании и многое умеет.

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

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

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

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



Ясно одно — по мере роста бизнеса обеспечение устойчивости к сбоям (даже не процедур восстановления после сбоев) становится всё более острой проблемой. От количества аварий в год начинает зависеть репутация компании, при больших временах простоя становится неудобно пользоваться сервисом, и т.д. Причин много.

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

Рады опубликовать интересную, на наш взгляд, статью нашего друга Николая Михайловского (хабропользователь nickm197). Думаем, что она будет интересна всем, кто профессионально работает в ecommerce.

Вступление

Когда мы приходим к потенциальным заказчикам рассказывать про сервис персонализации crossss, один из частых вопросов: «А как он внутри устроен-то?». Пользуясь дружественным блогом компании CentroBit, расскажу немного теорию и практику устройства рекомендательных сервисов.

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

Начнем с самых азов и философии.

Доброго времени суток, уважаемые Хабраюзеры!

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

Рисунок 1 – Взаимная блокировка 1-го рода с участием сигнальной переменной.

В рамках этого поста мы рассмотрим проблемы, которые возникают при использовании сигнальных переменных, и покажем, как их можно избежать.

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

Не так давно мне принесли небольшую программку (менее 1000 строк, более четверти — комментарии и пустые строки) с задачей «сделать что-нибудь красивое, например, графики и интерфейс». Хоть программа и небольшая, а переделывать её не хотелось — дядька её ещё два месяца будет старательно обкатывать и вносить коррективы.

Результаты работы в виде нескольких кусков кода и вагона текста старательно изложены под катом.

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

Собственный класс. Выбрасывайте исключения на основе собственного класса, унаследованного от Exception, а не напрямую — на основе Exception, потому что это дает возможность определить свой собственный обработчик и отделить отслеживание и обработку исключений, выбрасываемых вашим кодом и кодом фреймворка .NET.

Отдельные поля. Создавайте отдельные поля в собственном классе для передачи существенной информации, вместо сериализации и десериализации данных в поле Message. Несмотря на то, что идея упаковки в Message сложных данных в виде строки типа JSON выглядит соблазнительно, это редко является удачной идеей, поскольку добавляет дополнительный расход ресурсов на кодирование, локализацию, декодирование.

Небольшой и полезный чеклист по usability. Проверьте свой ресурс перед тем как перейти к юзер-тестированию. Не претендует на «столп usability», которому необходимо следовать, но здесь собраны довольно полезные вещи.

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

Мы против таких способов анализа информации. Потому каждый желающий может скачать подготовленную нами гуглотаблицу, ответить на вопросы “Да” или ”Нет”, отфильтровать ответы и получить результат и план действий.

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

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