Alpha-Beta-Release Blog

Приветствую всех читателей. Если отойти от сугубо теории и технических моментов криптовалют, то, по факту, в каждой второй новости будет что-то типа “стартап из Сан-Франциско запускает” или “Компания Х заявляет”. Или же “Правительство / Центробанк / Регулятор страны Y предупреждает или запрещает”. Не вникая подробно, складывается впечатление, что все компании с криптовалютами или преследуются гонениями, или находятся в США. Либо компания полностью анонимная и тщательно скрыта - вполне реальная ситуация, постоянно пользуясь каким-либо сервисом, вдруг оказывается, что кто стоит за ним и где он зарегистрирован (кроме доменного регистратора) совершенно непонятно.

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

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

Полная версия на сайте издания Bitnovosti.com

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Oracle, купив Sun, подготовило закат солнца вручную, медленно убивая самую лучшую СУБД в мире – MySQL. Но что делать, если очень хочется быстрой и свободной базы, но без  призрака оракла за спиной?

Твой любимый форум работает на MySQL (на мускуле, если кратко), а на работе или в вузе крутиться система учета чего-либо, написанная твоими друзьями под пиво и за получение зачета? И тоже на мускуле? Да в вебе тысячи и миллионы сайтов используют MySQL как базу данных. Но что будет теперь, когда ненавистный и глубоко противный истинным опен-сорсникам Oracle купил многострадальную Sun, а заодно и наш с тобою любимый мускул? От неудачников, кинувших даже ЦРУ, не стоит ждать качественного развития свободных проектов. Да-да, я отвечаю за базар – первым проектом молодой компании Oracle была разработка по заказу разведчиков какой-то учётной системы, за которую на конкурсе другие компании просили под 2 млн, а молодой Ларри Элисон заносчиво запросил за все жалкие 300 тысяч. Стоит ли говорить, что проект был провален, зато компания получила стартовый капитал и начала свое восхождение. Хотя уже поздно бить тревогу, все пацаны давно в курсе, что лучший (читай – наименее ущербный) движок для хранения данных в мускуле – это InnoDB, права на который у Oracle были давным давно. Так что, если ты сейчас чешешь репу, что бы выбрать взамен MySQL, ты удачно открыл журнал, я расскажу, чем можно заменить поделие империи зла. Но не беги с криками «да ваш мускул г…, бери слона (PostgreSQL) и будет все зашибись» - сейчас столько кода написано с поддержкой мускула, и зачастую в виде единственной базы данных, что переписать или искать замену себе дороже, а часто просто невозможно. Хорошо, если это форум или блог, обычно там сразу поддержка нескольких систем, а если что-то самописное и заточенное под возможности именно MySQL? Так что задача у нас с тобой самая что ни на есть простая – сохранить мускулы, но прокачав их так, чтобы не зависеть от старшего тренера и его стероидов. Oracle, конечно же, выступила с заявлением,  что все в порядке и будут развивать все по старому, но никто как всегда не поверил. Даже быстрый выпуск версии 5.5, которую многие ожидали, не дал положительных результатов – старые баги как были, так и остались, но по маркетинговым заявлением все ОК.

Разработчики и идеологи самого мускула далеко не дураки и сами предвидели ситуацию, что после поглощения всем будет не очень сладко, поэтому некоторые решили покинуть от греха подальше компанию и основать свои проекты, прихватил тогда еще свободные коды MySQL. Таким образом, сейчас есть несколько проектов, которые взяли за основу оригинальный сервер, но постепенно дописывали или переписывали все, до чего могли дотянуться. И первым делом – освободились от бремени InnoDB, правами на который обладает тот самый Oracle. На замену ему выкатили несколько движков, основной из которых – MariaDB. Читать далее...

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Интернет устарел и об этом все знают! Сначала думали, что все обойдётся, но когда в Сети появились толпы людей, которых не интересовали скучные технические отчеты и документация, это стало очевидно. Сеть требовала красоты и функциональности – изображений, анимации, видео и аудио. Чтобы показать на странице все, что взбредет в голову дизайнера, приходиться очень напрягаться и разработчикам браузеров и составителям стандартов. Так, из обычного формата разметки текста, HTML превращался в мультимедийного гиганта, на базе которого делали страницы интернет-магазинов, банковские системы, он-лайн игры и твои любимые порносайты. Возможностей стандарта HTML 4 уже мало, но как по мне, он устарел сразу в момент создания. Первыми фишку потребностей народа просекли в Macromedia, давно купленной гигантом Adobe, выпустив сначала Shockwave, а потом и Flash, теперь уже именуемой платформой (раньше это был всего лишь плагин к браузеру и уродский простенький язык программирования анимации).

Flash дал то, что всем так хотелось – видео, звук и анимацию, возможности программировать графику и создавать более-менее реальные приложения. Для особо одаренных есть возможности объединить javascript и Flash (замечу, очень по уродливому и ненадежно), таким образом дополняя упущения разработчиков браузера. Видео заполонило мир, Youtube, Фейсбук и вКонтакте стали самыми популярными сайтами - ага, из-за флеша, потому что без видео и приложений, которые почти все флешевые, они нафиг не нужны.

Но разработчики стандарта HTML тоже просекли фишку - надо дать народу новый стандарт, чтобы все делали свое дело не уходя из обычной платформы браузера во всякие Flash/Silverlight/JavaFx. А то иш ты, наплодили своих плагинов, соревнуются в разных фишках, хотя, по честному, все это костыли и предназначение у них лишь одно, пофиг какая технология, лишь бы видео и звук был. Ладно, еще 3D графику и будет круто! Пользователям это нужно ставить, обновлять и вообще, браузер из основного окна в мир сети стал ненужной прослойкой для запуска приложения на флеше или сильверлайте (а разработчики это давно смекнули, потому добавили возможность работы вообще вне браузера - Adobe AIR и Desktop-режим в Silverlight).

Короче, ну ты понял – сети потребовался новый стандарт взамен устаревшего HTML. Его и придумали, незатейливо обозвав HTML5. Это уже не только и не столько язык для разметки страниц и их форматирования, но и руководство для разработчиков браузеров, какие возможности они должны предоставлять странице и выполняемому там коду. Javascript хоть, хорошо, оставили как основной скриптовый язык. При этом вторгаясь в совсем не HTML область, поручили браузеру дать невиданные возможности скриптам. Отныне работа с видео и звуком, двух и трехмерной графикой, анимацией, эффектами, сетью на низком уровне – все это должно быть доступным в обычном JavaScript. Читать далее...

Приветствую своих читателей. График новых постов совсем сбился, это всецело моя вина. В закромах есть уже два материала готовых, ожидаю когда будет публикация на сайте журнала Хакер, с которым я теперь сотрудничаю. А сегодня я предлагаю краткий но интересный пост об архитектуре Twitter-а. Основой послужил это  материал, крайне рекомендуемый для прочтения всем - Архитектура Twitter. Два года спустя (Иван Блинков, сайт http://www.insight-it.ru).

Cтатистика (взято из insight-it.ru):

• 752% рост аудитории за 2008 год
• 1358% рост аудитории за 2009 год (без учета API, по данным comScore)
• 120 миллионов зарегистрированных пользователей
• 9й сайт в мире по популярности (по данным Alexa, год назад был на 12 месте)
• 70 миллионов твитов в день (800 в секунду в среднем, пики до 2000)
• Каждый твит читают в среднем 600 раз, то есть 1.2 миллионов показов твитов в секунду
• 600 миллионов поисков в день
• Лишь 25% трафика приходится на веб сайт, остальное идет через API
• 6 миллиардов запросов к API в день, около 70 тысяч в секунду

А с помощью чего это достигается? Читать далее...

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Развелось сегодня разных платформ, немеряно просто. У каждого уважающего себя пацана стоит Linux, у странных личностей все еще пыхтит винда, а вероотступники пересели на MacOS и смотрят на всех свысока. Черт, а загляни в карман – там этих гаджетов тоже немало. Кульный iPad, вместе с собратьями, Google лезет во все щели на рынок со своим Android OS, а еще есть никому не понятные но популярные у буржуев Balckberry и, тьфу тьфу, Windows Mobile. Зоопрак прям, верно? А ты просто бедный программист, потому что очень ведь хочется написать один раз программу, воплотить свой шедевр, и потом легким движением руки запускать ее везде. Да, есть java, на которой думалось, что все будет везде работать, но фиг там, не особо получилось. Если на десктопах еще более менее (а сколько ты знаешь массовых программ на Java, которые везде одинаково работают – Eclipse да и все), то с мобильной стороной у Java все очень плохо, и даже JavaFX не помогает. Хотя внутри Андроида и лежит Java, но и там она сильно урезанная и подогнанная под возможности мобилок. Так что, если захочешь писать под все это разнообразие, готовься учить под каждую платформу свой язык, компилятор, ограничения платформы и API, в отдельных запущенных случаях еще и среду разработки и саму платформу, ведь для iPad/iPod/iPhone особо не попишешь без реального устройства и железного мака (на виртуалку не надейся, много заморачиваться надо).

Но лень, как говориться, двигатель всей ИТ-мысли, поэтому появились предприимчивые парни из стартапа Appcelerator, которые выложили в открытом виде специальный фреймворк и систему разработки Titanium. С ним жизнь сразу становиться лучше и светлее – ты пишешь программу один раз, используя только одно API, а потом компилируешь одним кликом, а в результате все работает на любой платформе. Интересно узнать как?

Читать далее...

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

The Art of Message Queues - для тех, кто хочет вообще понять, о чем речь, когда говорят про сообщения, очереди и брокеры. Хорошее введение в тему.
[slideshare id=4182369&doc=art-of-message-queues-100520171613-phpapp02]

Читать далее...

Приветствую своих читателей. Сегодня мы продолжим начатую ранее тему о веб-приложениях реального времени и поговорим о серверной части. Буквально на днях по аське у меня состоялся разговор по теме онлайн игр и архитектуры движка для реалтайм игры. Оказалось, мы оба думали про одно и то же, а именно, использование NodeJS как сервера для ядра системы, обслуживающего клиентские подключения. Конечно, построить весь технологический стек современной браузерной игры полностью на NodeJS все ещё затруднительно, да и сам процесс написания масштабных приложений на серверном JS еще не изучен. А вот держать комет-подсистему, которая отвечает за мгновенную доставку нужных данных клиентам - для этого Node  подходит идеально. Но давайте отложим рассмотрение этой части, здесь тема не на одну статью, а поговорим про создание распределенной системы обмена данными для серверной платформы. Читать далее...

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Comet… чё за …?

Сегодня все в Интернете хочет быть быстрым, очень быстрыми. Ты даже не успел загрузить страничку в Facebook или вКонтакте, а твои друзья уже узнают, что ты онлайн и пытаются вызвать в чат. На других сайтах ты можешь видеть уже не просто ники пользователей, а сразу начать с ними общаться – и это не просто личные сообщения, как было в форумах в лихих 90-х, а полноценные чаты типа аське. Добавил Вася новую статью в блог, ленту новостей которого ты читаешь? Она должна сразу появиться у тебя в ридере, если, конечно, ты сейчас его читаешь. Задержка, любое промедление сразу ставит крест на любом ресурсе, нацеленном на общение. Посмотри на всякие конференции стартапов и первые страницы популярных ресурсов  - везде умные слова вроде real-time, collaborative и communication. Что за …?

Отвечаю! Если раньше веб-приложения были, как и обычные сайты – просто страницы и ты должен был ходить по ссылкам, чтобы обновить информацию, разве что по таймеру обновлялись фреймы, то теперь все иначе. Все хотят, чтобы информация приходила к нам сама в момент появления, а не ждать и тыкать сто раз в рефреш, ожидая, когда же твой друг наконец появиться в сети. Такие требования поставили перед разработчиками новые задачи, существенно усложнив жизнь, но, а что делать? Так и родилась технология Comet или, по простому, набор приёмов и средств для обновления данных (страниц или их элементов) в браузере без твоего участия. От тебя надо только залогиниться и зайти на сайт – в социальную сеть, онлайн игру или другой ресурс. От этого момента, если какая-то новая информация появляется, сервер сам отправит твоему браузеру новые данные. Читать далее...

Приветствую читателей. Погода за окном просто требует чего-то горяченького, поэтому воспользовавшись возможностью что-то по исследовать в свободное время, я решил подумать - а можно ли не останавливая скрипт, подменить функцию, которая выполняется? С таким требованием я встретился чуть ранее, при разработке нашего стартапа. У нас был один из внутренних серверов, который заведовал всеми действиями между пользователями в реальном времени. Это обычный РНР-демон-роутер, который обрабатывал запросы от клиентских запросов (внутри сервера), но была одна сложность - в случае, когда я что-либо изменял в коде сервера или обработчиков отдельных команд, демон приходилось перезагружать, что означало отключение текущих клиентов и потеря информации о состоянии сервера (этот вопрос решаемый, конечно). То же самое было в случае ошибки в коде - все подключенные пользователи сразу это чувствовали на себе (хорошо, что все они такие же разработчики, а не реальные клиенты). Можно ли этого избежать?

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