Вы можете делать всё, что вам нужно, с помощью Meteor, и вы можете делать это легко. Такой подход вдохновил разработчиков на добавление команды meteor deploy, которая должна была волшебным образом закрыть все потребности в развёртывании приложений. Но не закрыла.

meteor deploy работает, только если вы используете облачное решение Galaxy (от 0.035 $ в час) или бесплатный хостинг на Meteor.com (который закрывается уже 25 марта).

Запустить приложение на своём сервере можно: нужно собрать его под выбранную платформу, отправить на сервер и запустить как обыкновенное Node.js-приложение. Правда, вместо запуска посыпятся сообщения об ошибках. Чтобы всё прошло хорошо, важно использовать правильную версию Node.js. Вот гарантированно работоспособная инструкция.

Бухгалтерия, регистрация, налоговая отчетность… После этих слов страшно начинать свое дело. Смелее! На самом деле все довольно просто. В статье я расскажу, как настроить бухгалтерский и налоговый учёт в интернет-магазине. Вы узнаете:

• как выбрать организационную форму для интернет-магазина – ИП или ООО;
• какую систему учёта выбрать – ОСНО или упрощёнку;
• как зарегистрировать ИП или ООО;
• какие документы должен выписывать интернет-магазин;
• где найти бухгалтера для интернет-магазина;
• как сдавать отчётность в налоговую.

Читайте, если собираетесь открыть свой бизнес или начать работать официально.

Привет, я занимаюсь фронтенд разработкой, и как-то так сложилось, что в своей повседневной работе активно использую vim.

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

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

Как ни странно — в статье много картинок ;)

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

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

Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

Теперь меня регулярно просят рассказать про Git и что в нем такого. Уже надоело, поэтому этот пост для тех, кто еще сомневается.

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

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

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

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

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

Хочу отметить, что вижу две цели составления бизнес-плана:

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

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

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

Еще один важный аспект бизнес-плана – это определение целей компании, но не в виде «заработать больше денег», а скажем «обеспечить лучшее качество» или «увеличить скорость обслуживания». Самое главное, что эти цели можно, или даже нужно, рассказать всем на фирме. Давно известно, что человек лучше делает что-то, когда знает цель, а не просто выполняет прямые указания.

Перейдем к главному: «что должен содержать бизнес план магазина?». Именно на примере Интернет магазина я и буду строить бизнес план. Изначально буду работать по следующему списку:

1. Общее описание проекта
2. Описание рынка Интернет торговли. В нашем случае это будет описание развития e-commerce в нашей стране, объемы ранка и т.д.
3. Описание рынка. Тут будет описан непосредственно конкретный товар.
4. Оценка конкурентов.
5. Целевая аудитория
6. Маркетинговое планирование
7. Основные фонды и человеческие ресурсы
8. Персонал
9. НИОКР – Научно исследовательские и опытно конструкторские работы – буду описывать создание сайта, а точнее ТЗ
10. Риски
11. Заключение

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

Оригинал статьи — "Начнем работу над бизнес-планом"

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

Не так давно Apple представила iPhone 5S, и сайт с презентацией, где страница была поделена на секции, и каждая секция описывала одну из особенностей продукта. Я подумал, что это – замечательный способ представления продукта, исключающий возможность пропустить ключевую информацию.

Я отправился на поиски подходящего плагина, и к удивлению, не обнаружил такового. Так и родился плагин постраничной прокрутки.

JavaScript занимательный язык программирования.

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

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

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

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

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Бен Кэменс обнаружил, что в выпадающем списке Shop by Department на сайте «Амазон» ховер-эффект происходит очень быстро, абсолютно без какой-либо задержки. Тем самым происходит нарушение старого, выработанного ещё в 90-х годах прошлого века правила: перед отображением пункта подменю необходим так называемый гистерезис, запаздывание.



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

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

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



Картинка кликабельна.

PS: Оригинал на английском здесь. Переводил на русский — не я.

Привет, Хабр!

В этой статье я бы хотел поделиться своими познаниями в кроссбраузерной и кроссмейлерной верстке почтовых рассылок. Под словом кроссмейлерность подразумевается — корректное отображение верстки во всех почтовых клиентах. Я считаю, что статья вполне актуальна, в виду того, что на хабре эта тема несколько раз освещалась, но некоторые нюансы были неточными, а другие просто устарели. По долгу службы я долгое время занимался версткой html расылок по всему миру, и приведенные ниже правила будут касаться следующих почтовых клиентов и веб-интерфейсов: MS Outlook 2003-2010, mail.ru, rabmler почта, Яндекс почта, Gmail, Yahoo! Mail (Classic), Thunderbird 2.0-3.0, Hotmail, Windows Live Mail, Apple Mail 3-4, AOL Mail, Lotus Notes 8-8.5.

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

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

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

Сайт копирует модель коллективной фильтрации от bash.org.ru — состоит из двух разделов: Сигнал (отобранные и разбитые по категориям картинки) и Шум (огромное количество картинок, добавленных самими пользователями, выдаётся пользователям рандомно). Время от времени, самые популярные картинки из Шума уходят в Сигнал, «попадают на главную» (заодно и в RSS валятся). Вот и всё. Можно только добавить, что крутится всё на django (nginx, apache+mod_wsgi), postgresql и prototype.

Приходите к нам смотреть на красивые сиськи!