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

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

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

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

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

Дело было вечером, делать было надо и для всех!



Итак, сегодня мне хотелось бы рассказать нашу историю о том, как нам удалось привлечь необходимые инвестиции для нашей мега разработки!
Собственно идея самого проекта довольно проста и лаконична – организация автоматизированного сервиса такси. Т.е любой желающий может сделать заявку «Я еду … » далее указывает адрес, а те кто желает подзаработать частным извозом отслеживают не рядом ли с ними расположен сей чудный пассажир.

Многим верстальщикам знакомы комментарии в фотошоповских макетах.



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

Верстальщик верстает. В течении этого процесса у него накапливаются комментарии для программиста к своей вёрстке.

Есть 2 способа передачи этих комментариев:

1. «тыкать пальцем» и рассказывать что, куда, когда и зачем
2. оставлять комментарии в коде

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

«Липкие листочки» фотошопа избавляют от такого «тыканья пальцем» дизайнера. Таким же способом можно избавить от данного процесса и верстальщика.

В 2002 году Марк Ньюхаус (Mark Newhouse) опубликовал статью «Укрощение списков» ("Taming Lists"), довольно-таки интересную часть которой он посвятил объяснению того, как создавать собственные списки, украшенные псевдо-элементами. Почти десять лет спустя Николас Галлахер (Nicolas Gallagher) изобрел технику, которая использует псевдо-элементы из спрайтов, для создания фоновых изображений.
Сегондя, основываясь на опыте гигантов, мы постараемся развить эту тему. Мы обсудим, как можно украсить элементы без дополнительной разметки, используя только технику CSS-спрайтов. Результат будет работать также в Internet Explorer 6 и 7 версии.

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

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

Сегодня мне пришел заказ от весьма крупной компании. Они просят реализовать на одном из их сайтов вот такое решение (орфография оригинала, названия изменены):

Пользователь на сайте заходит в «Калькулятор стоимости решения „ЗАО Рога и Копыта“.
Там он отвечает на 11 вопросов для расчета стоимости решения. После этого пользователю должно быть предложено заполнить свои ФИО, должность, название организации и email.
На указанный email должно быть отправлено уведомление: „По указанному адресу в скором времени Вам будет выслана стоимости решения “ЗАО Рога и Копыта», на основе заполненной на сайте rogaiko.pyta анкеты".
На нашу почту должены прийти контакты пользователя и ответы на вопросы. В течении суток мы рассчитываем решение и высылаем на указанный адрес.
(прим.авт. — средняя стоимость решения более миллиона рублей).

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

1. «Калькулятор» означает устройство, которое выполняет расчет и выдает результат сразу.
Называя онлайн-сервис «калькулятором», мы как бы обещаем пользователю, что после того, как он потратит свое время и заполнит анкету, он сразу получит важный для него результат.
Если это не так, если над ответом будут трудиться живые люди, и придет он через пару дней, то мы не должны обманывать пользователя, называя этот сервис «калькулятором». Этот сервис правильнее назвать «запрос ценового предложения». Это операция совершенно иного характера, и заниматься такими запросами будут совсем иные люди с иной целью.
Особенно вызовет раздражение пользователя ситуация, когда о том, что это на самом деле не калькулятор, он узнает лишь после того, как заполнит и отправит анкету.

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

Я — обычный офисный работник. То есть, наёмный, но на территории плательщика и на его условиях. Да ещё подписавшийся на этот хитрый типовой трудовой договор: «исполняю функциональные обязанности + приказы руководства (обычно — всякий бред, с моей профессий связанный слабо)». В общем, веду образ жизни, знакомый многим из нас, и который большинству сменить щелчком пальцев весьма сложно. И пока я ещё в нирвану не прорвался, неслабо встал вопрос: а как же мне жить комфортнее в такой кабале. Ответ получился чуть философским, чуть экономическим, чуть психологическим, но он есть. И его скрывать преступно.

В конце 2010 года Грем Белл и Ричард Боддингтон опубликовали работу «Solid State Drives: The Beginning of the End for Current Practice in Digital Forensic Recovery?» («Твердотельные накопители: начало конца существующим методам судебного восстановления данных?»), которая вызвала неоднозначную реакцию интернет-сообщества. И хотя обсуждаемая в указанной статье особенность работы твердотельных накопителей была впервые озвучена в 2008 году на конференции DEFCON 16, исследована специалистами компании Майкрософт и представлена на конференции разработчиков машинных носителей информации в 2009-м [1, 6-й слайд] и даже упомянута на российских семинарах в 2010-м [2, слайды 10 и 11], признание проблемы и серьезное обсуждение этих особенностей в сообществе криминалистов пришлись на март 2011 года.

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

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

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

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

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

В последнее время со стороны компаний, занимающихся цифровой безопасностью, стало довольно модно сообщать об успешных операциях по закрытию ботнетов и аресту их владельцев. Так, закрыли Bredolab — и об это не написали только ленивые.

Цель этой статьи — показать, что далеко не всё так гладко в Датском королевстве.

Автор не претендует на исчерпывающую информацию, но в любом случае полезно знать о провалах антивирусной индустрии.

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

Всем привет.

Этот пост навеян заметкой на Хабре "Будьте внимательны к своим покупателям" и личным опытом. Прямого отношения к Копини пост не имеет. Лояльность, удовлетворенность, качество поддержки, бла бла бла. Это конечно круто, но что это реально дает компаниям? Стоит ли так «облизывать» клиентов и заботиться о них?

Под катом небольшая история о банке, Светлане и деньгах.

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

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

Итак, ранее мы познакомились с основными ресурсами, доступными в сети для анализа файлов.

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

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

В этом случае на помощь нам приходит оффлайн-решение проблемы.

Картинка из книги Thinking Forth

По мотивам «обобщенной» статьи про GOTO и статьи про GOTO в системном программировании:

Мотивы для использования GOTO и альтернативы ему принципиально отличаются для системного и прикладного программирования — это является и важной причиной холиваров. Для прояснения ситуации рассмотрим GOTO только в разрезе прикладного программирования.

Основной тезис: в прикладном программировании GOTO однозначно лучше обходить.

Как докажем:

1. В прикладном программировании критически важен один параметр кода — сопровождаемость.
2. Goto не ухудшает однозначно сопровождаемость только в небольшом проценте случаев, и даже в этих случаях принципиально от альтернатив не отличается
3. Ради небольшого процента случаев его использовать вредно:
   1) очень низкоуровневое, поэтому сильно развращает программиста (возникает соблазн использовать и в других местах) — большой вред из-за небольшого процента случаев, когда GOTO можно применить;
   2) даже в таких случаях есть более красивые альтернативы.

26-летний белорус Дмитрий Насковец признался в управлении веб-сайтом CallService.biz, через который было осуществлено более 2000 случаев кражи личности. На него работала сеть немецко- и англоговорящих операторов, которые обзванивали банки, притворяясь жертвами кражи личности и подтверждая фродовые транзакции, осуществляемые сообщниками.

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

Где-то в начале 2010 года я узнал об очень интересной для меня теории, которая очень много чего объяснила для меня в жизни. Я о ней писал уже на Хабре habrahabr.ru/blogs/ui/111401.
Хотя я сам занимаюсь бизнесом сфере консалтинга и психологии, но большýю часть своей жизни был связан с IT и программированием. И вот мне пришла в голову мысль – выпустить приложение для iPhone, выпуск которого очень много всего изменил.
Ну, как и всегда, все началось с идеи. Идея приложения была следующая: дать пользователю инструмент, с помощью которого он бы смог легко распознавать модели поведения других людей, и чтобы это приложение давало конкретные ответы на вопросы «Как?» и «Каким образом?» взаимодействовать с тем или иным человеком в разных ситуациях.

Под катом в деталях описан процесс создания приложения и много всего интересного с суммами в USD и картинками.