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

Всем привет!

Меня зовут Лекс и я ведущий youtube-канала "АйТиБорода". А еще я дотнетчик со стажем в 6 лет. Недавно у меня появилось желание выйти за рамки своей основной технологии (C#/.NET), и познать суть парадокса Блаба. Я твердо решил, что попробую себя в другом языке, и выбор волей случая пал на Go.

Для того, что бы получать знания структурировано, я записался на курс от mail.ru, который вы можете найти тут: https://www.coursera.org/learn/golang-webservices-1. Собственно о том, что я вынес из первой недели обучения на этом курсе, дальше и пойдет речь. Погнали!

Привет, Хабр! Этой статьёй я открываю цикл материалов, посвящённых работе с большими данными. Зачем? Хочется сохранить накопленный опыт, свой и команды, так скажем, в энциклопедическом формате – наверняка кому-то он будет полезен.

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

Начинать надо от простого к сложному, поэтому первая статья – о принципах работы с большими данными и парадигме MapReduce.

Предлагаю вашему вниманию перевод статьи «Responsive Upscaling: Large-Screen E-Commerce Design» автора Christian Holst.

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

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

1. Только 18% из 50 ведущих американских интернет-магазинов, которые мы тестировали ранее, в этом году адаптировали свой дизайн под большие экраны (в то время как у 94% этих сайтов дизайн адаптирован под мобильные устройства).
2. Почти три четверти электронных продаж все ещё совершаются на ПК, а не на мобильных устройствах (смотрите здесь, здесь и здесь).
3. Около трети этих пользователей приходят с экранов шире 1350 пикселей (смотрите здесь, здесь и здесь). (Примечание: Разумеется, есть разница между шириной экрана и шириной браузерного окна — реальное число пользователей с браузером указанной ширины будет ниже. Мы рекомендуем вам отслеживать размеры браузерного окна в вашей веб-статистике для более полной картины того, насколько значителен этот сегмент для вашего сайта.

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

Мы уже рассказывали о дата-центре фотосервиса imgix, а сегодня затронем тему повышения производительности MySQL и взглянем на советы инженеров соцсети Pinterest.

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

Видео проигрывалось в почтовых программах Apple Mail и Outlook 2011 для Mac. В остальных почтовых клиентах отображалось обычное изображение. Ниже представлено пошаговое руководство по созданию такого видео-письма.

Статья 1. Почему я не преподаю SOLID

Если вы разговариваете с кем-то, кому небезразлично качество кода, уже достаточно скоро в разговоре всплывёт SOLID — аббревиатура, помогающая разработчикам запомнить пять важных принципов объектно-ориентированного программирования:

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

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

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

Школьники уже, кажется, сдали ЕГЭ и вот-вот отправятся подавать документы в ВУЗы. Программирование и IT-технологии пользуются стабильным спросом, примерно как юридические и экономические специальности 10 лет назад.

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

Процесс покупки в интернете затягивает — один раз попробовав купить товары онлайн, покупатели осознают все преимущества удаленной покупки. Ведь так здорово иметь магазин всегда под рукой: заказать еду, билеты, выбрать бытовую технику и многое другое, находясь в любом месте и в любое время. Приятные ощущения от комфортной покупки в сочетании с отработанной маркетинговой активностью интернет-магазина заставляют клиента возвращаться снова и снова. Это подтверждает статистика: российский рынок онлайн-покупок за 2014 год вырос на 35% — до 560 млрд рублей, а количество покупателей выросло на 37%, до 25,4 млн человек. Всего в интернете россияне совершили 195 млн покупок и потратили на них на 41% больше, чем в 2013 году, — 645 млрд рублей. Средний чек с учетом стоимости доставки составил 3 300 рублей.

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



В ходе совместного исследования MasterCard и UsabilityLab, посвященного юзабилити процесса покупки в интернет-магазинах, были выявлены основные ошибки, допущенные на каждом из этапов. Любая такая ошибка — риск потерять покупателя или отвлечь его внимание на сторонние страницы и сервисы. Цена ошибки очевидна — потеря прибыли. Стоит отметить, что осознание погрешностей в оформлении и совершенствование страниц происходит достаточно быстро. Исследование стартовало в конце 2013 года — за этот период некоторые платежные системы внесли в свои страницы значительные изменения и улучшили юзабилити. Это можно увидеть, сравнив примеры из этого поста и просмотрев современные решения, предлагаемые пользователям на крупных сайтах.

Разобьём результаты по этапам покупки и рассмотрим, что же было сделано не так и какие риски вызывали те или иные некорректные параметры.

Я — программист. А ещё я слеп. Слеп, как крот, как говорится. Таков я от рождения.

Когда я говорю об этом своим товарищам, то те из них, у кого никогда не было проблем со зрением, обычно задают один из трёх вопросов:

• Как же ты тогда можешь читать то, что я пишу?
• Ого. А как ты тогда можешь кодить?
• Или — самый популярный вопрос — А ты видишь сны?

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

Думаю, многим хорошо знаком класс DataTable. Вычитывая из БД на клиент большие таблицы через ADO.NET, иногда приходится продлевать время жизни экземпляров этого класса на продолжительное время. Например, если нужна обработка и анализ полученных данных, не прибегая к ORM материализации (да, лучше бы это делать в БД, но далеко не всё порой удаётся туда вынести). Когда объём данных невелик, то особой проблемы с этим не возникает. Однако на широких таблицах с большим числом строк можно получить довольно толстые объекты в памяти. Сопоставив объём данных, приходящих из БД, и размер получаемого DataTable, можно прийти к двум выводам:

• При больших объёмах varchar данных, среди которых есть дублирование, можно попробовать организовать некое подобие интернирования строковых данных внутри DataTable;
• DataTable содержит довольно увесистую внутреннюю инфраструктуру. Манипулируя с типами данных и числом строк в таблице, удалось установить, что процент накладных расходов составляет 15-20% для таблиц от 100 тыс. записей. Большая часть инфраструктуры обеспечивает корректное редактирование и прочий функционал таблицы. В случае, когда вам требуется, чтобы DataTable был простым контейнером для данных, полученных из БД, то можно написать лёгкий выпотрошенный аналог этого класса.

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

В первой части статьи я кратко описал принципы RESTful и объяснил каким образом следует проектировать архитектуру вашего сервера так, чтобы можно было легко выпускать новые и прекращать поддержку устаревших версий вашего API. В этой части я кратко расскажу о HATEOAS и Hypermedia, а затем расскажу о роли, которую они могут сыграть при разработке нативных приложений для мобильных устройств. Но главной темой этой статьи будет реализация кэширования (точнее поддержка кэширования на стороне сервера). Целевая аудитория включает разработчиков серверного ПО и, в какой то мере, разработчиков под iOS или под другие мобильные платформы.

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

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

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

Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), — снизу.

Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API — это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем представления. Объедините все прямоугольники с API и обзовите слоем сервисов.

Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.

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

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

Вы получили логическую архитектуру приложения. Разбросайте слои по серверам — получите физическую архитектуру.

Теперь вам остаётся детально проработать каждый маленький квадратик.

Маленький практический пример запрячу под кат.

AJAX-вызовы вывели работу web на новый уровень. Уже не нужно перезагружать страницу в ответ на каждый ввод информации пользователем. Теперь возможно отправлять вызовы на сервер и обновлять страницу на основании полученных ответов. Это ускоряет работу интерактивного интерфейса.

А вот что AJAX не обеспечивает – так это обновления с сервера, которые необходимы для работы приложения в реальном времени. Это могут быть приложения, в которых пользователи одновременно редактируют один документ, или уведомления, рассылаемые миллионам читателей новостей. Необходим ещё один шаблон для рассылки сообщений, в дополнение к запросам AJAX, который бы работал в разных масштабах. Для этого традиционно используется шаблон PubSub («publish and subscribe», «публикация и подписка»).

Какую задачу решил AJAX

До появления AJAX интерактивные взаимодействия со страницей были тяжеловесными. Каждое из них требовало перезагрузки страницы, которая создавалась на сервере. В этой модели основной единицей взаимодействия была страница. Неважно, какой объём информации отправлялся из браузера на сервер – результатом была полностью обновлённая страница. Это была трата как трафика, так и серверных ресурсов. И это было медленно и неудобно для пользователей.

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

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

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

Пролог

Сайты иногда падают. Такое случается. Но вот то, что описано в статье, случаться не должно.

#1

Недавно зашёл на сайт одной компании и увидел (в очередной раз, замечу) вместо него сообщение об ошибке:



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

Первая ошибка (слишком очевидная, но…): показ сообщений об ошибках. Да, все знают, что нужно отключать дебаг в продакшене. Но, чёрт возьми, почему я регулярно вижу сообщения об ошибках в своём браузере?!

Привет, Хабр! Я работаю интерном в Санкт-Петербургском центре разработок ЕМС и хочу дать студентам пару советов о построении будущей карьеры, а также рассказать про задачи, которыми занимаюсь в компании. В этом году за одно из своих решений я получил награду Bright Internship Award как лучший стажёр Центра, и мне интересно получить обратную связь по достигнутым результатам. Эта статья может быть интересна тем, кто занимается тестированием производительности систем.

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

Можно, конечно, воспользоваться классическими приколами типа:
• спросить подопытного, как расшифровывается слово «ДУНЯ»; предложить свой вариант «Дураков У нас Нет»; и дождаться недоуменного «А Я?»;
• напихать в фотодатчик мышки испытуемого ворсинок или просто заклеить его скотчем (в смысле, датчик)…

Но можно применить и более высокотехнологичные и изощренные способы «сноса крыши» с помощью программ-шуток.

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

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

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

Чтобы использовать AppCache, создается файл описания с расширением «appcache», например, manifest.appcache. В этом файле можно перечислить все файлы, которые должны кэшироваться. Чтобы включить эту функцию на вашем сайте, необходимо включить ссылку на этот файл описания на вашей веб-странице в html-элемент следующим образом: