В последнее время все чаще можно наткнуться на круговую панораму в интернете. Взять к примеру тот же сырный домик. Это эффектная штучка возможно вскоре станет обыкновенным делом для сайтов ресторанов, гостиниц, отелей и т. п. Однако, что делать, если существуют проблемы с flash на компьютере? Это реальная ситуация, которая возникла у меня на работе, по причине жесткой политики безопасности IT-отдела.
    В этой небольшой статье я расскажу вам о трудностях, которые встретил на пути создания интерактивной панорамы на WebGL + THREE.js.

В статье Как я искал работу voff написал замечательную фразу:

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

Это правда. Программистов ищут везде, от Москвы и Киева до Берлина и Сан-Франциско. Другой вопрос – как программисту эту возможность использовать? Пройти 17 собеседований, “по 3-4 в день”, как сделал автор статьи – на такой экстрим не все согласны. Да и подходит это только тем, кто сейчас без работы или уже обьявил о своем уходе руководству. А хорошие разработчики без работы сидят редко.

Наверняка вы слышали о сервисах Amazon EC2, Rackspace и им подобным. Может быть даже пользовались. Лично мне бывает нужен иногда личный VPN-сервер. Для этих целей я уже давно держал микро-инстанс на Амазоне, предоставляемый им в течении первого года бесплатно. Плюс использовал для архивов Amazon Glacier, который с его ценой «1 цент за гигабайт в месяц» можно считать тоже почти бесплатным. Но вот год закончился и за EC2 стало нужно платить. Архивы мои тоже разрослись прилично и затраты на Glacier аналогично перестали радовать.

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

Я сильно ошибался. Ниже будет рассказано как на базе DigitalOcean сделать себе VPN-сервер в пару десятков раз дешевле такого же на Амазоне и сервис хранения архивов, в бесконечность раз дешевле Glacier.

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

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

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

Введение

Всем Buenos Dias! В своей статье я хотел бы максимально лаконично и просто рассказать о том, как построить процесс автоматизированного тестирования web-приложения с нуля. Первым делом нужно правильно расставить приоритеты и выбрать приемлемое соотношение цена/качество. Сразу определимся — это будет не решение «на коленках» из зоопарка скриптов, которыми часто пользуются при ручном тестировании. В тоже время мы не будем тратить много усилий на проектирование нашего «фреймворка» для автоматизации. Наша цель — предоставить результаты своей бурной деятельности перед руководством в максимально короткие сроки, при этом система должна быть:

• максимально простой, чтобы тесты могли писать даже специалисты по ручному тестированию
• гибкой и расширяемой, поскольку мы не можем адекватно оценить весь объем работ на данном этапе
• кроссплатформенной (Selenium WebDriver C# поддерживает Firefox, Chrome и IE)

В своем примере я буду успользовать .NET (Microsoft Unit Testing Framework) и Selenium WebDriver C#.

Ни для кого не секрет, что e-mail маркетинг только начинает набирать обороты во всем мире. А для России – это ещё и вовсе молодая ниша на рынке. И профессиональная верстка электронных писем здесь один из составляющих факторов успеха. Под профессиональной версткой понимается не только визуально красиво и надежно сверстанный макет, но и то, как выглядит usability открытки с маркетинговой точки зрения, как оптимизирована графика вместе с типографией для спам-фильтров и многое другое. Верстка электронных писем довольно обширная тема, в одной статье все не уместить, поэтому в данном посте постараюсь описать только базовые элементы и приемы, надежно проверенные за годы практики и работающие в top самых используемых почтовых клиентах мира: iPhone 4S/5; Outlook 07/10/13; iPad; Apple Mail; Android 2.3/4.0; Yahoo; Gmail. Если рассматривать только российский рынок, то нельзя не упомянуть о Mail.ru и Яндекс.Почта.

Что нужно знать в начале?

Сразу хочу выделить несколько из основных и важных моментов:

1. В нашем арсенале имеется очень урезанный набор css-свойств, которые поддерживаются всеми почтовиками. При этом, стили нужно прописывать inline, а в head выносить только вендорные свойства и те блоки объявлений, которые не несут нагрузки на основную стилизацию письма. Ну и использовать link in head — крайне нежелательно.
2. Не используйте background-image в основных визуальных элементах дизайна и не помещайте в изображения важную текстовую информацию. Вообще нужно всегда учитывать такой вариант, что письмо будет просматриваться получателем без единого изображения.

Каркас

Пожалуй каждый, кто хоть раз верстал письмо под рассылку, знает, что каркас лучше строить с помощью таблиц. На самом деле простая блочная модель div поддерживается на данный момент во всех перечисленных выше почтовиках, за исключением MS Outlook начиная с 2007 версии. Это связано с тем, что в качестве движка последние версии Outlook используют Microsoft Word, который в свою очередь много не знает о блочных css-свойствах. Игнорировать при верстке данный почтовый клиент я не рекомендую, поэтому в качестве фундамента все же используйте table. Да и добившись хорошего результата для Outlook, можно быть уверенным, что в большинстве почтовиках, письмо будет смотреться тоже хорошо, а скорее и лучше.

В качестве примера рассмотрим наиболее важные элементы из следующего, не сложного шаблона:

Поклонником телевидения я никогда не был, поэтому без какого-либо дискомфорта около 6 лет пользовался стареньким кинескопным Samsung примерно такого же возраста. Играл и фильмы смотрел на ноутбуке, а сам же ТВ включался лишь изредка, для «фона».

С приобретением игровой консоли xBox 360 я всерьез задумался о покупке современного телевизора, так как играть на старом кинескопном было практически нереально. Во-первых, в нем попросту нет HDMI-порта, и приходилось довольствоваться обычными «тюльпанами» и переходником SCART. Во-вторых, в силу низкого разрешения экрана нельзя было насладиться всей полнотой графики современных игр, а мелкие надписи (например, пояснения в играх) и вовсе были нечитабельны. Выход виделся один – приобретение современного телевизора.

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

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



То что вы делаете, называется интеграционным тестированием. Современные приложения достаточно сложны и содержат множество зависимостей. Интеграционное тестирование проверяет, что несколько компонентов системы работают вместе правильно.

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

Приветствую всех!

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



В статье будут описаны и решены следующие задачи и цели:

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

Думаю, не мне одному чрезвычайно надоели ресурсы, требующие регистрации по каждому поводу и без. С обязательной капчей, которая правильно введется только с пятого раза, с подтверждением по е-мейлу, которое обязательно свалится в спам и то — только через сутки. Придумывать каждый раз новую пару логин-пароль — забудется, вводить одно и то же на всех сайтах — небезопасно. Местами прокатывают пары вида «qwerty:qwerty» или «login:password», но, увы, далеко не везде. Надоело. Не счесть, сколько раз я, увидев надпись «только зарегистрированный пользователь может ****», просто кривился и закрывал вкладку, чтобы больше ни разу на этот сайт не заходить. Неужели администраторы ресурсов сами этого не понимают?

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

В целом, это хочется делать просто и понятно. При этом хочется разумного компромиса. Я встречал некоторые библиотеки, которые дают мощный функционал, но при этом по объему — десятки килобайт JavaScript кода. Несколько десятков килобайт, чтобы, например, подменить параметр в QueryString? Эх…

Несколько лет назад в «Разрушителях мифов» Адам и Джемми сооружали «Трубу Рубенса». Это было так зрелищно и прикольно, что я очень им позавидовал. Ну а теперь, когда подвернулась возможность построить нечто подобное, удержаться от соблазна было невозможно.

Текстовый редактор bootstrap-wysiwyg — это всего 1.5 Кб в минифицированном и сжатом виде и чуть больше 6 Кб исходного кода, базовые функции редактирования на основе execCommand, drag-and-drop для вставки изображений, поддержка стандартных горячих клавиш и ничего лишнего. Редактор работает в современных браузерах (Chrome 26, Firefox 19, Safari 6) и на мобильных платформах (IOS 6 iPad/iPhone, Android 4.1.1 Chrome). Зависимости — jQuery, jQuery HotKeys и Bootstrap.

Я пишу сайты на asp.net mvc. В этих 16 главах я хочу рассказать, как я это делаю. Это некий учебник-справочник всех тех знаний, которые я накопил в течение трех лет.

Почему именно asp.net mvc

ASP.NET MVC я люблю потому что:

• Это .net. Я знаю .net и С#.
• Это компилируемый код.
• Это не ASP.NET WebForms, я работаю с html-кодом.
• Используется MVC-паттерн.
• Visual Studio – самое популярное средство разработки, в котором есть IntelliSense.
• Отличные инструменты отладки.

Доброго времени суток!
В этой статье я расскажу, как повысить производительность многопоточного (и не только) C#-приложения, в котором часто создаются объекты для «одноразовой» работы.
Немного про многопоточность, неблокирующую синхронизацию, использование встроенного в VS2012 профилировщика и небольшой бенчмарк.

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

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



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

Мне очень нравятся выпадающие меню из Bootstrap. Благодаря простой и понятной семантике их легко и приятно использовать при верстке.

Но для полного счастья мне не хватало некоторой функциональности.

Потребность

При разработке веб-приложений очень часто возникает необходимость отображения постов пользователя или сообщества из социальных сетей. У социальных сетей есть свои виджеты, которые подключаются через iframe, со своим внешним видом и стилем. Что если нам нужно отображать посты одновременно из нескольких социальных сетей с возможнстью изменения дизайна отображения? Если это пара twitter и facebook, то существует несколько плагинов, выполняющих эту задачу. Принимая во внимание, что популярность социальной сети Вконтакте на территории СНГ очень высока, то есть необходимость плагина поддерживающего и эту сеть.

За время своей работы верстальщиком, мне довелось иметь дело с кучей разных макетов как от новичков дизайна (или порой просто левых людей), так и до профессионалов. И за это время я успел набрать приличную выборку наиболее типичных багов в макетах, которых не в состоянии избежать даже маститые специалисты. Сразу оговорюсь — в некоторых организациях есть внутренние «требования к дизайн-макетам», и по идее, при несоответствии дизайна этим требованиям, он должен без вопросов отправляться на доработку, но реалии таковы, что зачастую проще самому внести нужные правки, чем гонять документ туда-сюда по трекеру. Но даже в этих «требованиях» упомянуты далеко не все очевидно возможные «косяки». Постараюсь привести наиболее популярные и универсальные (без личностной привязки). Да, кстати, все баги привожу под использование фотошопных psd — ну уж де-факто это стандарт в веб-макетах. Да и не попадались мне ещё макеты в векторе (и надо сказать, слава богу).