Сегодня наткнулся на ресурс под название Wix.
Тут можно создавать флэш сайты имея под рукой арсенал из drop shadow, glow, blur… и предлагаемые ресурсом готовые анимации типа fade и прочего. Так же есть подключаемые виджеты: mp3 player, google maps… Можно выбрать готовые шаблоны, одним словом тот же народ.ру только по-американски. Как вы думаете для кого создан такой русурс: для ленивых псевдо-сайто-мейкеров или серьезно настроеных бедных фотографов?

Итак, вы написали свое супер веб-приложение на Java и теперь хотите что бы как можно больше людей его скачало, задеплоило и начало пользоваться? Все отлично, только для для некорых java-прораммистов, особенно для тех, кто последние цать лет прожил в мире J2EE может быть открытием, что для 99,9% людей в этом мире слова «Просто задеплойте этот WAR-ник на ваш любимый сервер» окажутся пустым звуком. Ну ок, может не 99,9% а 99,8% — ну или около того.

Ниже следует первая часть туториала о том, как из вашего варника сделать красивый Windows Installer (да-да, мало того что большинство людей не знают слова деплой, так они еще и Windows пользуются!) с использованием WiX

На самом деле речь тут пойдет уже не о Java. Допустим, у вас есть некторый zip с некоторой программой (например созданный в первой части) — и вы хотите сделать для него msi (для установки через Windows Installer). Это может быть что угожно — jetty + ваш war, апач плюс php-ха — в данном случае это уже не важно. Важно что это «нечто» — что надо после установки запустить в качестве сервиса

Как это сделать при помощи WiX под катом

Для начала — что такое WiX? Технология WiX (Windows Installer XML) представляет собой набор инструментов и спецификаций упрощающих процесс создания дистрибутивов на базе MSI (Microsoft Installer). Если объяснять проще то это обертка вокруг MSI с человеческим лицом.

На мой взгляд изучать проще всего на простых примерах. В данной статье я приведу пример простейшего инсталлятора.

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

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

Custom Actions один из важнейших элементов в WiX, позволяющий производить любые действия в процессе установки или удаления программы, раширяющий возможности WiX. С помощью Custom Action мы можем подключить к нашему установщику VBScript, JScript, Dll библиотеку, исполняемый модуль и производить любые действия в процессе работы инсталлятора.

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

В этой статье я поделюсь с вами практическим опытом, полученным за много лет создания инсталляторов в Фаматек. Под катом — теоретические выкладки и практические инструкции, как безболезненно и «по феншую», совместимым с «Windows Logo Testing» способом создать инсталлятор, предлагающий пользователю выбрать язык установки и устанавливающий продукт на выбранном языке. При этом используются исключительно бесплатные решения.

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

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

Естественно я сделал его в виде подключаемого файла для сборки в wix. Получилась ситуация что часть модулей в различных инсталяциях имеет одинаковый ComponentId.
Вроде как это допускается, поскольку у продуктов разный ProductId/UpgradeCode, а отслеживание компонентов ведется по связке ProductId.ComponentId. Это специально уточнялось в свое время в одном из блогов разработчика Wix.

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

Товар в красивой упаковке проще продавать. А программу в хорошем инсталляторе?

Ведь не факт, что инсталлятор — аналог упаковки. Это скорее процесс вынимания продукта из коробки. Много раз нажать «Next», в самом конце — «Finish», и никакого там аккуратного развязывания ленточек. Порвали слюду, небрежно вскрыли коробку — «Что там у нас внутри?»

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

Приветствую.

Не знаю как вам, но мне сначала совершенно не хотелось ставить новую Windows 8. А смысл? Смысла не было, семёрка отлично работала и продолжила бы работу, но… Умные люди из Microsoft любят всё переделывать заново и в этот раз они конкретно переборщили.

Дело в том, что новая версия эмулятора WP, Windows Phone Emulator (XDE), использует технологию Hyper-V, которая в семействе настольных Windows появилась только начиная с Windows 8.

У меня возникла идея любой ценой установить этот SDK себе в VS2012 под Windows 7 и выжать из него максимум возможностей.

Внимание!

• Эмулятор будет доступен только для WP 7.1 и ниже;
• Blend будет доступен только для WP 7.1 и ниже, а значит XAML под WP 8 придётся писать руками;
• Это just for fun, ведь нормальные герои всегда идут в обход!

Под катом я вкратце расскажу, как устроен установщик WP8 SDK и покажу кривой путь через болотце для тех, кто не хочет расставаться с Windows 7, но хочет продложить разработку под новые версии Windows Phone.

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

Добрый день всем! В своей прошлой статье я поставил задачу генерации патчей и начал обзор технологии их создания на Wix (с использованием PatchWiz). Там же мы пришли к выводу, что для полноценного решения задачи нужно «что-то еще». Добро пожаловать в часть 2, где я опишу наши организационный и технический подходы со всеми исходниками.

От переводчика: англоязычные it-блоггеры обычно начинают такие статьи со слов I'm so excited. Про Wix# я узнал совершенно случайно и спешу поделиться этим открытием с хабрасообществом, т.к. каждый, кто имел дело с «голым» WiX, знает, насколько неприятным может быть этот процесс. И вот теперь можно сделать msi-дистрибутив, написав всего лишь несколько строчек на C#! По-моему, это круто! А относительно недавно (4 дек 2014) автор Wix# Олег Шило дал интервью изданию InfoQ. Перевод этого интервью я и представляю вашему вниманию. И прошу не судить строго за кальку некоторых слов — тот же «деплоймент» мне как-то ближе, чем «развертывание».

Привет Хабр!

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

Недавно на хабре я прочитал переводную статью про Wix #, о нем и пойдет речь.

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

Итак, представьте разбросанный по нескольким серверам набор приложений: 12 штук. Приложения разнородные, разработаны разными компаниями в разное время. Реализованы различные методы интеграции от примитивных экспортов/импортов через файловую систему, до продвинутой на базе web-сервисов. Приложения используют базы данных SQL Server и Oracle. Все эти приложения работают в сотнях разных окружений конечных заказчиков.

Установить и сконфигурировать все это стоит немалых трудов и ресурсов. Хорошо, установили. А обновления, которые для бухгалтерских систем должны выпускаться в соответствии с изменениями в законодательстве? Масштабирование приложений? А новый функционал? Что насчет новых клиентов с их «особенными» конфигурациями? Вручную – дорого и долго, если у вас, скажем, 150 клиентов и хотя бы 2 обновления такого «монстра» в год.

Привет, Хабр! Это первый пост конструктора сайтов Wix, сегодня мы расскажем о том, что представляет из себя наш продукт с технологической точки зрения, как работают наши инженеры и какие убеждения мы разделяем при разработке и деплойменте (который в Wix происходит каждые 7 минут).

Но обо всем по порядку.

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

За последние годы NoSQL-системы стали господствующим направлением. Многие разработчики видят в NoSQL-системах, таких как MongoDB, Cassandra, Redis или Hadoop, оптимальный вариант для построения своих приложений, считая их единой семьей продуктов, которая обесценивает старые SQL-системы.

Зачастую, в основе решения об использовании базы данных NoSQL лежит рекламная шумиха или ошибочное убеждение, что реляционные базы данных не могут обеспечить такую же производительность, как базы данных NoSQL. Когда доходит до выбора базы данных, инженеры часто упускают из виду эксплуатационные расходы, а также соображения стабильности и зрелости технологии. Чтобы узнать больше об ограничениях и изъянах различных NoSQL (а также SQL) систем, обратите внимание на серию статей проекта Jepsen, опубликованную на Aphyr.com.

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

Всем доброго времени суток.

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

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

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

1) Небольшая годовая плата (100 евро) за хостинг и готовый шаблон;
2) Большое количество шаблонов в html5;
3) Наличие мобильной версии;
4) Поисковая оптимизация (SEO);
5) Есть Yandex Metrica, что важно для проведения рекламных кампаний;
6) Есть почтовый хостинг на Gmail, но оплачивается отдельно (1500 руб в год);
7) Много положительных отзывов на просторах интернета.

Сравнили с inSales, но нам он показался дороговатым для старта, хотя по функционалу он был выше.