Введение

Не секрет, что мы наблюдаем бурное развитие облаков aka Clouds. Все и вся переезжает в эти самые облака. Но какую пользу (и вред) мы из этого можем извлечь с точки зрения ИБ?

Рассмотрим новые возможности и новые угрозы.

Вот, тезисные посылки, чтобы уменьшить сумбурность изложения.

1. Хранить в облаках — небезопасно.
1.1. Не надо хранить там ваши пиратские коллекции.
1.2. Прятать надо грамотно, разбавляя шумом.
1.3. Толика здоровой паранойи не помешает, шифруем сами.

2. Обрабатывать в облаках — выгодно.
2.1. Для этого надо строить облачные сервисы по-новому.
2.2. Пережить атаки теперь проще.

3. Злым хакерам теперь тоже проще — собрать ферму для взлома паролей может каждый.
3.1. Используем пароли побезумнее и подлиннее, не из словаря.
3.2. Используем Keepass и аналоги для управления паролями.
3.3. Везде где можно — переходим на ключи.

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

Readability for iPhone

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

Пури́зм (лат. purus — чистый) — преувеличенное стремление к чистоте литературного языка, к изгнанию из него всяких посторонних элементов […], чтобы развитие языка протекало свободно от внешних, случайных влияний и чтобы в наличный состав его не входили чуждые и ненужные ему примеси. wikipedia

 

Очень живое интервью с Игорем Шойфотом. Игорь живет в Сан Франциско, создал 10 стартапов: Epsilon Games, Fotki.Com, TMT Investments и др. Сейчас он занимается новым стартапом, инвестициями в рамках фонда TMT Investments, а также преподает в Калифорнийском университете в Беркли (UC Berkeley). Начинал проект Fotki.Com со своим co-founder'ом Дмитрием в конце 90-х с той идеей, что рано или поздно люди начнут держать свои фотографии в интернете. Ребята одними из первых придумали инструменты для продвижения с различными виральными механизмами.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Мы с другом решаем пойти в поход от Сан Франциско до Лос Аджелеса, чтобы заскочить в гости к нашим друзьям на Ньюпорт Бич. Посмотрим на карту и примерно прикинем путь по берегу:



Путь займёт около 400 миль, в день мы можем пройти 4 мили в час по десять часов, так что придём мы туда примерно через 10 дней. Мы звоним друзьям и бронируем столик на 6 вечера в воскресенье.

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

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



В отчете «Анализ форм» отображается время, которые пользователи тратят на заполнение той или иной формы, показывает какие поля формы при отправке остаются незаполненными и какое поле побуждает оставить заполнение и покинуть страницу.



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

Кстати, веб-аналитик Андрей Юнисов (webprofiters.ru) прислал нам полезное видео о том, как применять возможности анализа форм на практике:

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

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

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

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

Эта статья была опубликована в блоге w3c в 2007 году, но складывается впечатление, что большая часть разработчиков ПО даже и не задумывается о проблеме длины текста. Сколько раз вы видели сообщения, не умещающиеся в алерт?

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

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

1) Вложение не более $10 000
2) Прибыль не менее $1 000 в месяц
3) Минимальная рутина

По первым двум пунктам все понятно. А вот по третьему пункту поясню. К тому моменту я уже работал в собственной компании (сфера финансов). Это был 2009 год. Последствия кризиса еще сильно влияли на основной бизнес и работы было непочатый край. Много времени отвлекать на сторонний бизнес автор не мог.
Подходящий случай подвернулся в октябре 2009 года.

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

Доброго времени суток, %username%!

О непрерывной интеграции можно почитать здесь и вообще поискать литературу на данную тематику, если станет интересно. Если Вы уже осознали всю выгоду использования CI, то продолжу развивать мысль. Наиболее популярные из существующих систем непрерывной интеграции: Hudson, TeamCity и CruiseControl. Во всех этих системах настройка билда обычно осуществляется через UI. Выбираем что надо сделать в окошке браузера — и билд автоматизирован (естественно можно написать свои скрипты и запускать их). Обилие настроек и всяческих примочек. И я подумал, а что сделали создатели этих систем? А сделали они просто команды для различных билдеров, компиляторов, тестирующих и прочих инструментов, чтобы разработчик не тратил своё время на эти вещи. А так ли много времени уйдет на написание своей системы и команд?

Привет, %username%.

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

Введение

Для начала рассмотрим, как устроено стереоизображение и как на него смотреть.

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

Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.

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

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