воскресенье, 22 января 2012 г.

Как увеличить ваш Klout Score

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

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

  2. Используйте ваши аккаунты в социальных сетях. На данный момент главными соцсетями, которые влияют на рейтинг Klout, являются Twitter, Facebook, LinkedIn, Foursquare и Google+. Ниже приведены описания действий в каждом из них для поднятия количества очков Klout.

    • Twitter: Чем больше ретвитов и упоминаний вашего аккаунта вы получите, тем лучше.
    • Facebook: Klout отслеживает, как много комментариев, сообщений на стене и лайков вы получаете. Чем больше их у вас будет, тем лучше.
    • LinkedIn: Такая же история, как и с фейсбуком. Klout считает Ваши комментарии и лайки.
    • Foursquare: Добавляйте подсказки (tips) и отмечайте как выполненные элементы в списке планов (в To-Do List).
    • Google+: Получайте комментарии, перепосты (Поделиться) и +1
  3. Создавайте качественный контент. Люди не будут ретвитить, упоминать, лайкать или плюсовать ваши материалы, если они не являются достаточно хорошими. Сфокусируйтесь на создании качественного контента для взаимодействия с вашим сообществом.

По материалам:
EverythingPastors: How to increase your Klout Score
The Official Klout Blog: What does Klout Measure?

воскресенье, 14 ноября 2010 г.

Web-программирование - получение кода страны для отображения флага по названию

При разработке веб-сервисов и сайтов иногда бывает необходимо отображать флаги стран (их изображения) по их названию. Для решения таких задач можно воспользоваться сервисом http://opencountrycodes.appspot.com/, который может отдавать их согласно стандарту ISO 3166-1 alpha-2. Примеры таких флагов можно найти и скачать в архиве на сайте famfamfam.com, где, например, для России есть файл ru.gif. Название файла "ru" и есть двухбуквенный код России (Russian Federation).

Приведенный ниже код на PHP будет получать с сервиса XML-данные и создавать на выходе файл country_code_names.php с массивом соответствий код=>страна $countrycodes, который можно инклюдить непосредственно или преобразовать в необходимый вид:


<?php

$xml = file_get_contents('http://opencountrycodes.appspot.com/xml/');
$xmlel = new SimpleXMLElement($xml);
$out = '$countrycodes'." = array(\n";
foreach ($xmlel->country as $country)
{
$code = strtolower($country['code']);
$out .= "'$code' => \"{$country['name']}\",\n";
}
$out .= ");";

file_put_contents('country_code_names.php', $out);

?>

пятница, 7 мая 2010 г.

Flagged Waiting for content уже много времени

Когда это сообщение Flagged Waiting for content висит уже довольно длительное время, то пора предпринять шаги для решения этой проблемы. Бывает такое, что требование изменить координаты или контактные данные в Google Places, которые также фигурируют в Google Maps /Карты/, не модерируются на протяжении нескольких месяцев! Это означает, что содержимое, которое Вами было опубликовано, было помечено, но ожидает ручной проверки содержания, что означает то, что Ваше изменение попало в очередь ручной проверки и иногда это задерживается. Причин может быть много, однако, можно найти выход всегда.

А ведь все рекомендации находятся тут: Flagged listings - Google Places Help Есть пункт в этом тексте:
Как долго займет рассмотрение моего объявления?
Время рассмотрения сильно варьирует. Новые тикеты, как правило, рассматриваются в течение 4 недель. Если статус Вашего листинга висит уже более 4 недель, то дайте нам знать здесь.

суббота, 1 мая 2010 г.

Yandex Яндекс rel nofollow

Яндекс начал поддерживать атрибут rel="nofollow" в ссылках. Если поинтересоваться по странице Почему в разделе "Внешние ссылки" отображаются не все ссылки?, то станет понятно:
Почему в разделе "Внешние ссылки" отображаются не все ссылки?
В сервисе отображаются все найденные роботом ссылки на ваш сайт. Причины, по которым некоторые ссылки могут не показываться:
...
ссылка содержит атрибут rel="nofollow";
...
Остальные ссылки должны быть видны. Новая ссылка, если с ней нет перечисленных выше проблем, через некоторое время после ее появления должна начать отображаться в разделе "Внешние ссылки".
Стоит отметить, что такие атрибуты уже давно учитываются поисковой системой Google и другими, а Яндекс начал использовать только недавно. Раньше приходилось закрывать ненужный материал тегом noindex.

пятница, 23 апреля 2010 г.

Программисты ошибаются. Компьютеры тоже…

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


Рассказывают, что в Америке в одной из вычислительных лабораторий на видном месте стоит небольшая витрина, на которую прилеплена бумажка с надписью весьма близкой по смыслу к встречающемуся в отечественных автобусах призыву: “При аварии разбить стекло молотком”. А в витрине лежат… счеты. Обыкновенные конторские счеты – далекий предок нынешних компьютеров. Смешно? Безусловно. Однако, как говорится, в каждой шутке есть доля… шутки, и призыв лишний раз перепроверить результаты компьютерных вычислений, пусть даже и при помощи счетов, не покажется столь уж абсурдным, если знать, к каким последствиям может привести ошибка при работе компьютера.


Эволюция IT

Компьютер непогрешим. Эта мысль, благодаря первым популяризаторам вычислительной техники и нынешней рекламе, прочно закрепилась в умах людей, уверенных в том, что уж “машина-то не подведет”. Увы, это неправда. Компьютеры ошибаются. И делают это достаточно часто. По крайней мере, гораздо чаще, чем того хотелось бы разработчикам. “Самый надежный компьютер – выключенный компьютер”, – шутят по этому поводу программисты. И их правоту подтверждает череда ошибок и сбоев, сопровождающих работу практически любой вычислительной системы.


Когда возник самый первый компьютерный сбой, доподлинно не известно (скорее всего, в первый же день после запуска вычислительной машины), зато можно точно сказать, что термин “bug”, обозначающий сбой системы, был введен в обиход в 1943 году. Случилось это в Америке, когда в компьютер Mark-II, использовавшийся военно-морскими силами США для баллистических расчетов, неведомо каким образом залетел мотылек. Пустяковое событие привело, однако, к плачевным последствиям. Бедное насекомое ценой собственной жизни вывело из строя вычислительную систему, закоротив контакты одного из бесчисленных реле внутри вычислительного “монстра”, и тем самым… вошло в историю. Грейс Мюрей Хоппер, работавшая в то время на Mark-II, позже так вспоминала об этом случае: “Когда к нам зашел офицер, чтобы узнать, чем мы занимаемся, мы ответили, что очищаем компьютер от насекомых (debugging). Термин “debugging” (отладка) с тех пор прижился и стал использоваться для обозначения поиска неисправностей в компьютере, особенно в программном обеспечении”. Ну а термин “bug” стал обозначать сбой в работе системы.


На первых порах основной причиной отказов вычислительных систем была ненадежность аппаратуры. Да по-иному и быть не могло. В том скопище десятков тысяч отдельных электронных и механических элементов, которое представляли собой первые ЭВМ, на протяжении рабочего дня почти наверняка находился хотя бы один слабый элемент приводивший к неполадкам в работе, а потому безотказная работа машины в течение достаточно длительного времени воспринималась едва ли не как чудо. Со временем, однако, “железо” стало более надежным, а вот программы… Программы по-прежнему пишутся людьми, а потому неизбежно содержат ошибки. Людям, увы, свойственно ошибаться…


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


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


Самый дорогостоящий дефис в истории

Одной из первых дорогостоящих (в буквальном смысле) компьютерных ошибок стала та, из-за которой американцы потеряли космический корабль-зонд Mariner-1, направляющийся к Венере. Случилось это в 1962 году. Ракета-носитель стала отклоняться от расчетной траектории сразу после старта с космодрома на мысе Канаверал. Пришлось руководству NASA принять решение о подрыве носителя, поскольку ракета вполне могла упасть на населенную территорию. Как результат – срыв программы космических исследований и фейерверк стоимостью в 80 миллионов долларов, именно во столько обошлось создание космического корабля. Конечно же, стали искать виновных. И вскоре выяснилось, что все дело было в одном-единственном дефисе. Его просто-напросто пропустили при подготовке текста программы для ввода в компьютер, управлявший полетом ракеты. Кстати, программа была написана на языке ФОРТРАН, а злополучный дефис, по выражению известного писателя-фантаста Артура Кларка, стал “самым дорогостоящим дефисом в мире”. Все-таки 80 миллионов долларов…


Кстати, еще одна неприятность с ракетной техникой, обусловленная ошибкой в программном обеспечении, случилась уже в 90-х годах. На этот раз пострадали бравые американские военные ракетчики, принимавшие участие в операции “Буря в пустыне”. К их удивлению, ракеты “Пэтриот”, использовавшиеся для перехвата в воздухе иракских ракет, периодически проходили мимо цели. Разбирательства начались после того, как пропущенная иракская ракета привела к гибели 28 американских солдат. Первоначально зародилось подозрение, что часть “Пэтриотов” технически неисправны. Однако созданная по этому поводу комиссия с удивлением обнаружила, что все обследованные ракеты абсолютно работоспособны. Вы уже, наверное, догадались, где пряталась ошибка? Конечно же, в программном обеспечении, использовавшимся американским зенитно-ракетным комплексом. Выяснилось, что система создавалась в расчете на то, что время ее непрерывной работы не будет превышать 14 часов, однако на практике комплексы непрерывно работали по 100 и более часов. Вроде бы пустяк, но оказалось, что используемое для определения времени программное обеспечение накапливало ошибки. За 100 часов работы набегала разница в 0,34 секунды. Программисты, оказывается, знали об этом, да посчитали факт несущественным...


Убийцы в белых халатах

Следующая совершенно жуткая история, связанная с ошибками в программном обеспечении, случилась в Канаде в 1987 году.


И связана она с разработанным компанией Atomic Energy of Canada Limited (AECL) медицинским аппаратом Therac-25, использовавшимся для радиационной терапии больных раком. Как и в предыдущих случаях, программное обеспечение злополучного аппарата содержало ошибки. В результате этого в период с 1985 по 1987 год несколько десятков больных, проходивших лечение на Therac-25, получили повышенную дозу радиации, а для четырех из них врачевание под управлением компьютера и вовсе закончилось трагически.


Проведенная по настоянию родственников независимая экспертиза показала, что причиной стали допущенные программистами AECL ошибки. Причем кое-что, по признанию самих производителей, конечно же, было отловлено на стадии разработки, а вот “несущественные”, с точки зрения инженеров компании, ошибки в программном обеспечении все-таки остались. Нэнси Левинсон (Nancy Leveson) и Кларк Тернер (Clark Turner), проводившие независимое расследование, записали в своем отчете: “Главный вывод из случившегося – концентрация внимания на отыскании в программе отдельных ошибок не гарантирует однозначной работоспособности системы в целом”.


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


90-е годы: череда ошибок

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


Одним из первых сбоев компьютерной системы, который ощутила на себе целая страна, стал сбой в работе компьютерной системы обработки междугородных звонков компании AT&T в 1990 году. Из-за этого абоненты компании почти на 9 часов лишились возможности звонить в другие города и страны, а сама неисправность стала едва ли не крупнейшей за всю историю существования этой телекоммуникационной компании. Поиск ответа на вопрос, почему же произошел сбой в работе системы, в конечном счете, вывел на одну-единственную строчку программного кода, которая и стала причиной возникшего отказа. Увы, шутливое высказывание о том, что всякая программа содержит, как минимум, одну ошибку, в очередной раз получило практическое подтверждение.


В 1994 году эстафету “программных ошибок” подхватила компания Intel. Неполадки в работе нового процессора, получившего имя Pentium, обнаружил профессор Томас Найсли (Thomas Nicely) из Линчбургского колледжа (Lynchburg College) в Вирджинии. Вот уж воистину в чужом глазу и песчинку заметим… Дело в том, что сбой работы процессора происходил лишь при весьма специфических условиях во время выполнения операций с плавающей точкой, и большинство обычных пользователей вообще никогда бы не столкнулись с этой проблемой.


Однако руководство компании Intel приняло эту информацию, что называется, близко к сердцу. Директор по маркетингу Ричард Дракот (Richard Dracott) объяснил это тем, что наличие ошибок может отрицательно сказаться на имидже продвигаемой на рынке марки процессоров Pentium. В результате Intel обязалась заменить всем желающим процессоры с обнаружившимися ошибками на новые образцы, управляющий код которых не содержал багов. Все это обошлось компании в кругленькую сумму (что-то около 450 миллионов долларов), а Intel с тех пор стала публиковать списки обнаруженных ошибок для всех своих чипов.


Следующая неприятность, связанная с ошибками в программном обеспечении, приключилась в 1995 году. На этот раз из-за программистов вовремя не был открыт новый… аэропорт! Но обо всем по порядку. В 1995 году в городе Денвере должен был открыться международный аэропорт, который пресса восторженно называла “аэропортом XXI века”. Предусмотренная проектом система обработки грузов поражала воображение: прием, отправка и сортировка багажа должны были производиться в автоматическом режиме, практически без участия человека. Увы, при испытаниях выяснилось, что роботизированные тележки натыкаются на стены, а грузы сортируются далеко не так, как того хотелось бы разработчикам. Причина – ошибки в программном обеспечении, использовавшемся для управления системой. Как следствие, аэропорт был открыт на 16 месяцев позже намеченного срока, что привело к убыткам, оцениваемым специалистами в размере, как минимум, 3,2 миллиарда долларов. Кстати, багаж в Денвере по-прежнему обрабатывается при участии людей. Доверить столь ответственное дело компьютерной системе администрация аэропорта побоялась. Как говорится, береженого Бог бережет...


Денверский скандал не был единственным. В том же 1995 году от ошибок своих программистов пострадала компания Intuit, специализирующаяся на производстве программного обеспечения для оформления налоговых расчетов и автоматизации бухгалтерии малых предприятий. В марте 1995 года выяснилось, что выпущенная компанией программа для оформления налоговых отчислений содержит ошибки программного кода, которые позволяют пользователям при некоторых обстоятельствах вносить изменения в записи на центральном сервере компании, где хранились данные всех клиентов автоматизированной системы налоговых расчетов. Разразился скандал, который закончился тем, что компания Intuit обязалась возместить любые убытки, понесенные клиентами в результате ошибок в программном обеспечении разработанного продукта.


Впрочем, для коммерческих программ чаще всего все ограничивается выпуском “заплаток” или “патчей” (patch) для устранения ранее выявленных ошибок. Особенно этим славятся программисты Microsoft, редкая программа которых обходится без десятков, а то и сотен “заплаток”. Причем официальные представители Microsoft признаются, что вся их новая программная продукция поступает в продажу с некоторым количеством недоработок. Так, например, по просочившимся в печать сведениям, Windows-2000 на момент выхода в свет (17 февраля 2000 года) содержала более 60 тысяч (!) ошибок и недоделок. Как тут не вспомнить историю, произошедшую в свое время с академиком А. Ф. Иоффе. Рассказывают, что инженерная работа Абрама Федоровича началась с ремонта ветхого моста.


Только что окончивший институт инженер-технолог сразу предложил план ремонта, благодаря которому мост можно было не только починить, но и привести в состояние, при котором он простоял бы десятилетия, вообще не требуя никакого ремонта. Реакция начальства была неожиданной. “Да что вы, сопляк, мелете! – возмутился руководитель будущего академика. – Ведь в этом случае все возможности ремонта будут исчерпаны и нам придется жить на одно жалованье!”. Не иначе, что и программисты зачастую руководствуются тем же принципом. А то ведь к полностью отлаженной программе никаких “заплаток” писать не придется…


В 1996 году отличились французы. Из-за ошибок в программном обеспечении 4 июня был прерван полет космической ракеты Ariane 5. Убытки в результате составили более 500 миллионов долларов. А причина крылась в том, что по недосмотру переменная, которая описывала горизонтальную скорость ракеты, была представлена целым 16-битным числом. В результате, как только эта значение переменной превысило 32 768 (2 в 15-й степени), система управления ракетой, что называется, “подвисла”, а “сошедшую с ума” ракету пришлось уничтожить.


В 1998 году ошибки в программе едва не привели к массовому отключению потребителей электричества в Калифорнии. Случилось это, когда двум новым диспетчерским компаниям, ответственным за перераспределение электроэнергии между ее производителями и потребителями, потребовалось подключиться к уже имевшейся системе диспетчеризации. Для этой цели по их заказу была разработана новая диспетчерская сеть и создано специальное программное обеспечение, позволявшее одновременно работать с 200 электростанциями. Все было готово к пуску 1 января 1998 года. На свое счастье, заказчики догадались “обкатать” программу в тестовом режиме и… отложили запуск проекта на 3 месяца. Именно столько времени потребовалось для окончательной отладки вскрывшихся при тестировании ошибок в программном обеспечении, которые могли бы привести к катастрофическим последствиям для всей сети электроснабжения Калифорнии. К слову сказать, убытки заказчиков из-за задержки с пуском системы были оценены в 90 миллионов долларов.


Ошибка века

Говоря о многочисленных случаях “ляпов” в программном обеспечении, конечно же, нельзя обойти вниманием еще одну ошибку, которая терзала умы программистов в течение по крайней мере пяти последних лет ушедшего ХХ века. Речь, как вы уже, наверное, догадались, идет о пресловутой “ошибке 2000 года”, получившей название Y2K. Для ее исправления была создана целая индустрия, дельцы которой получили немалые прибыли, играя на страхе пользователей перед надвигавшимся компьютерным безумием. По всему миру на предотвращение “ошибки 2000 года” было потрачено около $200 млрд. Но, как говорится, пронесло. А суть проблемы состояла в том, что по утвердившемуся еще в 70-х годах обыкновению для обозначения порядкового номера года использовались всего лишь две цифры. Следовательно, при наступлении 2000 года тысячи компьютеров по всему миру не смогли бы отличить 2000 год от 1900. Для домашней “персоналки” это не так уж и страшно, а вот для банковских, транспортных и прочих систем, жестко привязанных к текущей дате, такая “оплошность” могла дорого обойтись.


Впрочем, несмотря на все предпринятые для исправления ошибки меры, кое-какие неприятности случились. Причем начались они еще до наступления 2000 года. Скажем, в Филадельфии в ноябре 1999 года несколько сот человек получили повестки из суда, обязывающие их явиться в суд в… 1900 году. А более 30 тысяч американцев с удивлением обнаружили в почтовых ящиках официальные уведомления из Управления социальной защиты США о том, что их пенсионные удостоверения подлежат замене, так как в 1900 году срок их действия истекает.


Впрочем, ничего глобального в связи с “ошибкой 2000 года” так и не произошло, хотя некоторые “несообразности”, связанные с этой ошибкой, время от времени давали о себе знать в течение всего 2000 года. Так, например, сбой, связанный с проблемой 2000 года, в информационной системе норвежской национальной железнодорожной компании NSB, произошел с опозданием на год. Утром 31 декабря 2000 г. ни один из новых поездов компании не смог вовремя выйти из депо.


Компьютеры были не в состоянии распознать текущую дату, что стало большим сюрпризом для специалистов, которые до наступления 2000 года тщательно проверяли все системы на устойчивость к ошибке тысячелетия. Никто из них не подозревал, что камнем преткновения станет не 1 января, а 31 декабря 2000 г. Из ситуации вышли достаточно просто: часы бортовых компьютеров установили на 1 декабря 2000 года. Обошлось...


Все бы ничего, да вот только мало кто из пользователей знает, что Y2K скорее всего еще вернется. Причина в том, что, по словам специалистов, в 80% компьютерных систем мира для предотвращения кризиса 2000 года применена мера, дающая лишь относительно краткую “отсрочку исполнения приговора”.


Вместо того чтобы просто расширить формат даты, используемый для представления года, с двух до четырех цифр, во многих случаях применен “сдвиг временного окна”. Этот нехитрый трюк, позволяет программе “догадаться”, относится дата к XX веку или к XXI. Как правило, номера лет из первой части поддерживаемого диапазона (например, от 0 до 30) считаются относящимися к новому интервалу дат, а остальные, например, 87 – к прежнему. Ясно, что мера эта временная и через каких-нибудь 30-40 лет “проблема 2050 года”, что называется, встанет в полный рост. Между прочим, и в 70-е годы тоже казалось, что до XXI века еще уйма времени...


Вместо заключения

Забавно, но один из методов проверки программы на содержание ошибок состоит в том, что в уже готовую и отлаженную программу нарочно вносятся… дополнительные ошибки. Удивлены? А нет тут ничего удивительного. Просто тестируемую программу с заранее внесенными ошибками дают на отладку программисту, который и пытается восстановить ее работоспособность. Если обнаруживаются лишь нарочно внесенные ошибки, то считается, что исходная программа ошибок не содержит. А вот если при поиске “эталонных ошибок” обнаруживаются и неизвестно откуда взявшиеся дополнительные недочеты, то программа, увы, должна быть признана сырой. Хороший метод. Надежный. Да вот только, как это замечено в одном из законов Мэрфи, “ошибки порождают новые ошибки”. Может, оттого и множатся ошибки в уже готовых программах?

Источник: Атлант

Эволюция компьютеров

суббота, 10 апреля 2010 г.

Автоматизация OpenOffice Calc и Writer из Delphi

Для автоматизации Open Office Calc в одной задаче мне потребовалось составлять документ по заранее заготовленному шаблону. Для решения этой задачи я воспользовался модулем для Delphi uOpenOffice.pas, который написан господином Yuri (aka Yuric74).

Текущая версия модуля для работы с OpenOffice Calc и Writer из Delphi доступна по адресу Версия от 23.10.2009, а обсуждение и предложения можно посмотреть на sql.ру в ветке Delphi (Дельфи) и OpenOffice (Опенофис).

В архиве находится тестовый пример с демонстрацией воpможности модуля, файл справки uOpenOffice.chm, сам файл uOpenOffice.pas.
Автоматизация Open Office из Delphi

Модуль uOpenOffice.pas годится как для автоматизации Open Office Calc, так и для автоматизации OpenOffice.Org Writer.

суббота, 27 марта 2010 г.

Сергей Брин жил при тоталитаризме, и это не нужно гуглу

Сергей Брин, начальник гугл, дал интервью, привожу отрывок:

Mr. Brin lived in the Soviet Union until he was nearly 6 years old, and he said the experience of living under a totalitarian system that censored political speech influenced his thinking — and Google’s policy. “It has definitely shaped my views, and some of my company’s views,” he said.

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