Яндекс.Метрика

Ни о чём

Ни о чём

WikiLeaks начинает публикацию писем «теневого ЦРУ»

WikiLeaks объявил о начале публикации пяти миллионов писем американской частной разведывательной компании Stratfor, которую называют «теневым ЦРУ». Компания занимается сбором и анализом информации о событиях в мире, на основании которой составляются экономические и геополитические прогнозы.

image

25 декабря 2011 года база данных Stratfor уже была взломана группировкой Anonymous. Вскоре часть данных была выложена в открытый доступ.

В новых сообщениях от WikiLeaks, относящихся к периоду с июля 2009 года по декабрь 2011-го, содержится информация об осведомителях Stratfor, системе выплат и психологических методах ее работы. Письма так же показывают, как разведывательная компания берет в разработку людей в интересах частных клиентов.

Ни о чём

Шрифт использующий точки вместо букв

Dotsies

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

Если верить сайту то за 20 минут можно освоить чтение данного шрифта.

Ни о чём

Кривые дракона и черепашка

кривые дракона
Существует замечательное и буквально завораживающее семейство фрактальных кривых — кривые дракона. Кто не знаком с ними принцип их построения проще всего объяснить при помощи полоски бумаги. Итак, возьмём полоску бумаги и сложим её несколько раз пополам, а затем развернем так чтобы между углами сгиба образовались прямые углы. В итоге мы получим кривую дракона. Поскольку толщина сложенной полоски каждый раз удваивается, а длина отдельного звена уменьшается в два раза, то мы не можем получить таким наивным способом длинных кривых.
К счастью длинные кривые легко рисуются другим способом, а точнее множеством способов. В частности, в Сети можно встретить рекурсивную программу порождающую кривую дракона достраивая катеты к отрезкам исходной кривой, как гипотенузам. Но я решил поручить это дело черепашке. Поскольку кривая дракона состоит из серии поворотов «налево» и «направо», то черепашка должна уметь только делать шаг в перёд и поворачивать. Главное, что я хотел увидеть — это сплетение кривых дракона. Да! Эти кривые сочетаются между собой в разных и интересных позициях, что кажется невероятным для таких сложных и запутанных кривых.

Ни о чём

Если бы языки программирования были машинами

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

Ни о чём

Privat1024 не от ПриватБанка

Проблема и решение.
Privat1024 не от ПриватБанка
Оказалось, что web-интерфейс сервиса Приват24 не влазит в 1024px по ширине. И получается, что корзина с подготовленными платежами оказывается за экраном и человек вынужден скролить.

Пришлось написать юзер-стиль. Может кому тоже облегчит жизнь.

http://userstyles.org/styles/61370/privat1024
— ни один элемент интерфейса не убран, только уменьшены в размере
— правая колонка сужена
— рекламные блоки отображаются полупрозрачными, чтобы не отвлекали

Вид при 1024px
image

image

В каком блоге лучше поместить такой топик?

Ни о чём

IT как часть жизни

Как-то я встречал уже топики на Хабре от людей примерно моего же возраста с занимательными историями их профессионального развития, которые направлены в основном на то, чтобы вдохновить других, кто еще встает на тропу IT. А это моя история, с некоторыми «пикантными» моментами в сфере ИБ, веб-разработки и т.д. Начну прямо с первых увлечений.

7-10 лет — радиоэлектроника

В то время у меня было много разных запчастей — лампочки на 1,5 В, провода, резисторы, моторчики и т.д. Баловался ими как только мог. Годам к 10 появились личные китайские рации и машинка от проводного пульта. Сборка-пересборка, перепайка, усиление антенны на рации с другом-электронщиком и так далее.
Конечно же — денди. Но чуть позже железо мне надоело т.к. я увидел…

10 лет — первый компьютер

Пока просто увидел. Это был Pentium 2 с Win 95. Меня привел в класс информатики в школе старший брат. Все, что мне разрешили — это поводить мышкой, на секунд 30. Я помню все еще пытался увести ее за монитор. Ожидал, что она сейчас уйдет за область видимости и это будет ошибкой, и нужно будет пытаться вернуть курсор назад. К моему сожалению, курсор уперся в рамки и не выходил за них. Это первое, что я попытался сделать с компьютером.
Сюда же вплоть до 12 лет — Sega MD. Перепайка джойстиков, которые вечно ломались, переходник для телевизора и т.д., не мне вам рассказывать.

Ни о чём

Бизнес-аналитика: «Как правильно написать список требований к системе?», Алистер Коберн, обзор часть 1

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


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

Основные понятия:

Use Case — последовательность шагов, которая обычно определяет все взаимодействия между какой-то ролью/функцией (в UML именуемой как «Аctor») и системой, для достижения какой-то определенной цели.
Actor — это в данном случае либо человек, который взаимодействует с системой, либо какая-то внешняя система, которая может запускать какие-то действия в нашей системе. Проще говоря, Use case это все варианты сценариев, всего того что происходит на странице.
Goals — цель, Goal failure — соответственно, недостигнутая цель.
Хороший Use case должен быть написан простым и понятным языком, чтобы информацию можно было легко и просто понять другому человеку.
Описывается основные характеристики:
Scope — что представляет собой проект или часть проекта,
Primary Actor (основное действующее лицо или элемент системы, инициирующий взаимодействие с системой в рамках главной цели) описание того, кто (пользователи/админы) или что будет работать на данной странице и
Level — уровень на котором все происходит;
Preconditions and Guarantees — что должно быть до и после запуска Use case;
Main success scenario — основной сценарий, что должно быть выполнено успешно;
Extensions — различные варианты, когда система отклоняется от основного сценария.
От себя хотелось бы отметить, мне очень понравилась ссылка на Стива Эдольфа, «используйте метод <погрузиться и всплыть>. Создайте основую модель высокого уровня, описывающую ваше представление о том, как могла бы работать новая система. Стремитесь к простоте, поскольку это неисследованная территория. Придумайте, как мог бы выглядеть основной сценарий, проиграйте его со специалистами по старой системе. Затем погрузитесь в один из ваших новых Use Cases. Просто задайтесь вопросом что происходит, в реальности, не вдаваясь в формальные требования <..> Наконец, вернитесь на поверхность, что изменилось после того как вы погрузились в детали? Настройте модель, а затем повторите погружение для следующего Use case...»

Общие правила


Стоят того, пожалуй, чтобы процитировать их полностью:

1. описание системы должно быть читаемо;
2. начинать всегда нужно с общей концепции, и переходить к подуровням,

Для каждого шага:

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

Для описаний данных:

Заносить в описание Use case только соответствующий ему уровень детализации.
Уровень детализации 1: Название данных
Уровень детализации 2: Поля данных, которые связаны с названием
Уровень детализации 3: Типы полей, длина поля и как именно происходит проверка достоверности внесенных данных.

Что не входит в use case, но всегда так или иначе с ним связано и нужно учитывать: форматы данных, протоколы ввода/вывода, требования к производительности и требования к интерфейсу пользователя, проектирование интерфейса пользователя, бизнес-правила.

Есть несколько стадий точности:
1. Действующие лица и цели: Перечислите действующих лиц и каждую из целей, которую будет преследовать система. Проанализируйте правильность и полноту этого списка. Расставьте приоритеты и распределите цели между командами разработчиков и версиями. Теперь у вас есть функциональные требования к первому уровню точности.
2. Краткое изложение Use case или основной сценарий: для Use case вы выбрали следование основному сценарию в общих чертах. Рассмотрите его в форме набросков, чтобы быть уверенным, что система действительно удовлетворяет требованиям участников, о которых вы заботитесь. Это второй уровень точности функциональных требований. Этот материал довольно легко набрать, в отличие от двух следующих уровней.
3. Условия отказа: Завершите основной сценарий и подумайте, какие отказы могут произойти. Занесите их в список, прежде чем решать, как система должна их обрабатывать. Описание процессов обработки отказов — более трудоемко, чем перечисление отказов. <...>
4. Обработка отказа: Напишите, как система должна реагировать на каждый отказ. Это часто непростой, утомительный и непредсказуемый процесс, поскольку при этом могут обнаружиться новые действующие лица, или новые цели, достижение которых должна обеспечить система.

Продолжение следует.

Ни о чём

ITSM, знание — сила

Часто в обсуждении или в статьях/комментариях встречаю «ITIL это теория поэтому оставим теорию и перейдем к практике».., читайте как «нам влом разбираться в том что люди изучали два десятка лет(а полагают что все пятьдесят), пора уже что-то делать..». И результатом нередко будут именно ошибки, собственные ошибки, те на которых так любят учиться и которые так ценят.

Из собеседования:
Employer: Расскажите о ваших завершенных проектах
Applicant: На прошлой работе 4 проекта завершили вовремя и успешно, не выйдя за бюджет
Employer: А проваленные были?
Applicant: Ну был один…
Employer: И какой вы опыт и этого вынесли? просто хотим убедиться что вы не наступите на теже грабли снова..

ITIL разработан на основе опыта тысяч компаний, их успешных реализаций процессов и их ошибок, именно поэтому его называют «лучшими практиками»(Best Practice, чтобы понимать откуда это словосочетание и не бояться его). Ошибок уже наделано компаниями в мире столько что если про каждую хотя бы пару строк писать то больше чем «советская энциклопедия» получится. Как вы полагаете не разумно ли учитывать чужие ошибки ??
Этим оканчиваем предысторию и подходим к основному посылу топика.

Перед публикацией материала на Хабре всегда просматриваю на наличие уже опубликованного и обратил внимание на то как мало пишут про ITSM и ITIL в целом, как мало переводов и ссылок на статьи о них, а ведь там заложена основа всех процессов происходящих в IT и как минимум ознакомиться с ними, про использовать на благо себе и заказчикам просто помолчим. Зато в ITSM сообществах материала немеренно, и в личных блогах.
Тут стоит вспомнить про карточку «Knowledge is power» из методологии ABC of ICT от Paul Wilkinson и Jan Shilt.
image
Она отображает одну из популярных ошибок в ITSM — нежелание делиться знаниями, полагая что это сделает тебя незаменимым. Посмотрим на себя самих в зеркало? — не это ли есть причиной того как мало материала про ITSM на торт размещают, может стоит быть таки ближе к тем кто использует ITSM? Позволю себе не согласиться с тем что создавать еще один блог про ITIL или ITSM эффективно для его популяризации фреймворка (разве что для самопиара, и то, много ли вспомнят тут блогов про ITIL? тем более русско-язычных).
Хотелось бы верить что это никак не связано с поддержанием спроса на ITSM консалтинг и ценности услуг в этом направлении, а связано всего-лишь с тем что методики иногда и на самих себя стоит применять, а не только для заказчиков.

P.S. написание топика навеяно комментарием к переводу.

Ни о чём

Quake 3 beta на WebGL


Брэндон Джонс, являющийся активным WebGL-разработчиком, выпустил новую beta-версию игры Quake 3 для браузеров. По заявлением разработчика, в релизе сделано несколько изменений, которые ускорили работу игры: обновлен glMatrix, полностью убран jQuery из проекта, началась работа над полноэкранном режимом. И действительно, игрушка показывает отличный показатель fps. Но главным отличием Брендон называет появившуюся поддержку геймпада. Хоть разработчик и не уверен, что побегать можно будет с любым устройством, однако проделанная работа впечатляет.

Конечно, проект еще находится в ранней стадии, ведь даже пострелять нельзя, но зато можно в полной мере насладится возможностями WebGL.

Попробовать можно тут.

Ни о чём

TechCrunch по-русски: И в стартапе, и в жизни вам нужен план A, B и Z

imageПримечание редактора: Рейд Хоффман – основатель LinkedIn и плодотворный инвестор. Этот пост – отрывок из его новой книги The Start-up of you, написанной в соавторстве с Беном Касноча.

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

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

Кто прав? Обе эти позиции не только правдивы, но и являются основополагающими. Предприниматели податливо настойчивы. Лучшие бизнесмены, с которыми я работал, обязательно выдвигали серьезные стратегии, но при этом не устанавливали четкого плана. В моей новой книге, написанной в соавторстве с Беном Касноча, «The start-up of you: будь готов к будущему, инвестируй в себя и меняй путь карьеры», мы показываем, как любой профессионал может использовать бизнес-методы, даже если он никогда не планировал создать свою компанию.

Ни о чём

Piwik 1.7

Вышла новая версия Piwik кратко:

Piwik является программой с открытыми исходными кодами для веб-аналитики. Он является преемником ныне прекратившей свое существование «phpMyVisites».

Также имеется система модулей и плагинов для наилучшего результата и производительности.

Изменения:
  • Новый отчет Web Analytics (Loyalty и Recency)
  • Более высокая производительность при отслеживании сотни и тысячи веб-сайтов
  • Улучшены PDF / HTML отчеты
  • Улучено юзабилити (макеты изменения панели, участки указания метрики на графиках)

Ни о чём

mysqlcheck и optimize таблиц InnoDB

Только что заметил, что если делать
mysqlcheck -o --repair db_name
и ваши таблицы в InnoDB, то не только не происходит repair (что и не должно, так как движок не поддерживает эту функцию), но и optimize не срабатывает.
То есть, база остается без optimize и вы этого не замечаете!

Если делать так:
mysqlcheck -o db_name
, то происходит пересоздание (recreate) каждой таблицы.

Из-за этого у меня optimize не выполнялся скриптом по крону уже полгода, с момента перехода с MyISAM на InnoDB.

PS: В моем случае используется innodb_file_per_table.

Ни о чём

Компьютерный класс в Грузии

Не так давно публиковал статью о том как Главе Крыма на открытии школы показали компьютерный класс с одними мониторами.

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

Да понятно, что это образцово-показательная школа, но...

Ни о чём

Отчет о 4й Киевской Хабравстрече

Очередная Киевская Хабравстреча состоялась. Под катом немного о мероприятии и видео докладов.

Хабравстреча состоялась 11 февраля в 12:30, в пабе По2л на Лукъяновке. “Привет” всем кто зарегистрировался и не пришел.

Было три доклада (двое из заявленных не состоялись по объективным обстоятельствам).

Сергей Шельпук — "Основы IPv6"
Сергей Гнидко — "Хостинг с нуля"
Максим Прокопов(CEO IT-Premium, it-premium.com.ua) — “Цифровая телефония на базе asterisk

по ссылкам видео, а фото тут

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

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

Приходите, приносите, посидим, пообщаемся…

P.S. Тем кто регистрируется и не приходит уже должны были почувствовать запах пепла рядом.

Ни о чём

Комикс на HTML5



Saizen Media сделали великолепный комикс с использованием html5.
Почитать комикс и увидеть возможности html5 можно по ссылке.

Ни о чём

Стартап — Abstruse Goose


Не бывает очень много Джонсонов для бизнес митинга (с)

Ни о чём

Определение доминирующих тонов на изображении [v 1.1]

После публикации прошлой статьи, я полностью забил на попытку выполнить алгоритм при помощи HSV или Lab координат. Забил на использовании библиотек цветов и вообще на сам скрипт забил.

Но что-то стало скучно и опять зачесались руки поработать с изображениями и одновременно захотелось исправить уже имеющийся алгоритм.
Скрипт: link

Ни о чём

Четвертая Киевская Хабравстреча

Новый год и новые Хабравстречи в Киеве. О следующей подробнее под катом



Ни о чём

Я хочу работать в Google! Телефонное интервью (часть 2)

Сегодня мы будет обсуждать технические аспекты и реализацию задач на Python и C/C++, которыми нас будет закидывать инженер из Google. Начнём с самых тривиальных проблем с последующим нарастанием сложности. Параллельно обратим внимание о чём стоит упомянуть во время интервью и где не попасть в ловушку.