В этой статье речь пойдет о довольно необычном проекте. Однажды меня посетило желание написать свой интерпретатор какого-нибудь скриптового языка и исполняющую машину для него. Просто для того, чтобы посмотреть, как оно внутри работает. Такая цель звучит не очень благородно и я отложил затею в долгий ящик, т.к. мне хотелось более полезной формулировки.
Как-то раз, один мой знакомый посетовал, что нужно написать скрипт автоматизации на WSH, но ни VBScript, ни Javascript он не знает. Тут «благородная» формулировка возникла сама собой… нужно помочь товарищу. В результате был написан компилятор и исполняющая машина, позволяющая исполнять скрипты для Windows Script Host, не прибегая к VBScript и JS. Под катом — краткая предыстория проекта и его внутреннее устройство и сам язык программирования.

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

В этой статье я хочу рассказать, как используя технологии WebRTC и Битрикса, создать своё мультимедийное веб-приложение.

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

В данной статье я постараюсь познакомить вас с замечательными утилитами Vagrant и Chef на примере автоматического конфигурирования development environment для PHP разработчика (на самом деле, PHP здесь только как пример, все нижеописанное может быть использовано для любого стека технологий).

Что будем делать?

Будем настраивать виртуальную машину (ВМ) с Ubuntu 12.04 для работы над проектом на PHP, а именно:

• Apache
• MySql
• PHP 5.4
• xDebug
• Memcached
• Composer
• Настроим сразу Virtual Host на определенную папку, доступную как с виртуальной машины, так и с реальной. Всё это параметризируем для удобства создания и использования.
• и другое..

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

Как это может помочь вам?

• Вы не хотите «засорять» свою систему множеством утилит, программ
• Вы хотите тестировать свой код в приближенных к production условиях
• Вы хотите тестировать свой код на разных версиях той или иной платформы (помните, как Travis тестирует билды в различных конфигурациях, например Symfony на разных версиях PHP)
• Вы не хотите больше помогать новому человеку на проекте (верстальщик, программист) устанавливать всё с нуля
• Вы хотите, чтобы у каждого человека в команде была идентичная среда для работы над проектом

Всё это — реальность. Вопрос только «как?».

Всем привет, нас зовут Leto, мы — английская компания, основанная двумя русскоязычными парнями. Мы создаем стартапы для наших клиентов. Иногда они обычные люди, которые решили начать свой бизнес и запустить стартап (например Sorted), а иногда это большие и состоявшиеся компании (например 20th Century Fox), которые пытаются запустить новый продукт или услугу. Мы помогаем им улучшить концепт, проработать бизнес-модель, мы разрабатываем сам продукт и создаем дизайн, запускаем, раскручиваем, анализируем — вобщем, мы стараемся делать все (или все из того, что требуется). Если вам знаком термин “lean startup”, то наш бизнес — это “lean startup as a service”.

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

Пока писал комментарий, автор перенес пост в черновики. Поэтому напишу сюда.

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

Пост хотел плюсануть, но просто не успел. Уважаю мнения, тем более хорошо изложенные!

На самом деле пост отличный, предлагаю автору вернуть его.

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

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

Расчет себестоимости

Говоря о стоимости создания сайта, начать необходимо с определения его внутренней себестоимости в самой компании. До сих пор многие студии работают по фиксированным тарифам (сайт-визитка – XXX рублей, интернет-магазин – YYY и т.п.). Но, так или иначе, все агентства продают время своих сотрудников, и определение себестоимости должно отталкиваться именно от этого фактора.

Заказчик покупает время производящих сотрудников (дизайнеров, разработчиков, специалистов по вносу контента и пр.). Он не готов платить за время PR-менеджера, бухгалтера, уборщицы. Поэтому расчетная смета на проект отталкивается, как правило, именно от стоимости часов «производящих ресурсов».

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

• ФОТ сотрудников – 50%
• — Производящие ресурсы (30%)
• — Менеджеры, обслуживающий и административный персонал (20%)
• Условно-постоянные расходы – аренда офиса, канцелярка, расходники, еда, техника и пр. – 15%
• Налоги – 20%
• Маркетинг и реклама – 15%

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

Итак, что мы представляем из себя на данный момент? В Stack Exchange сейчас работают 75 человек, примерно половина занимается продажами (маркетинг и реклама), остальные же — созданием продуктов (разработка, дизайн, управление сообществами). БОльшая часть удалённо работающих сотрудников занимаются разработкой: 16 удалённых и 18 офисных разработчиков, сисадминов, дизайнеров. У нас команда-гибрид, которая, как мне кажется, лучшая в мире. Я руковожу отделом проектирования, так что буду говорить в основном о разработчиках, но это применимо ко всем должностям.

Добрый день!



Ниже небольшая заметка, адресованная тем, кто так или иначе влияет на академическое образование в нашей стране. Потому как после трёх лет упорной работы по развитию пресловутого «образования 2.0» я вынужден сделать вывод, что слишком мало руководителей нашей высшей школы понимают общую стратегию мировой академической среды.

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

Итак, сначала немного пафоса.

Предупреждение: Никаких подробных инструкций не будет! Только последовательность действий, необходимые шаги и наводки. Это руководство только для опытных администраторов Линукс!

Примеры некоторых моих конфигов прилагаются...

Замечание: эта статья написана на основе экспериментов с 32-битным CentOS 6.3 (Для сервера необходимо использовать 64-битную ОС. Но так получилось, что на доступном мне для экспериментов железе 64-битный CentOS не установился.) Однако разницы для методики установки нет (32 vs 64bit) — она только в суффиксах дистрибутивных файлов: либо i686 (или i386), либо x86_64…

Содержание:

• 0) Подготавливаем серверное железо
• 1) Устанавливаем Операционную Систему (ОС)
• 2) Настраиваем Сеть
• 3) Настраиваем менеджер пакетов (yum)
• 4) Устанавливаем дополнительный софт, не относящийся к системе 1С
• 5) Настраиваем Samba-сервер
• 6) Достаём и готовим дистрибутивы 1С: Предприятие… Откуда всё взять?
• 7) Сборка и Установка «СУБД PostgreSQL от 1С (релиз 9.0.3-3.1C от 17.01.12)» на Линукс CentOS (6.3)
• 8) Установка «Сервера 1С: Предприятие 32bit для RPM-based Linux-систем (8.2.16.368)» на Линукс CentOS (6.3)
• 9) Установка защитных ключей (лицензирование 1С)
• 10) Далее, устанавливаем клиентскую часть — на другой машине под управлением Windows
• Литература (использованная и дополнительно рекомендуемая)

Введение

Здравствуй, уважаемый хабраюзер.Я хотел бы тебе представить материал о практическом создании компилятора, который будет транслировать код, написанный на языке Cool, в код виртуальной машины CIL (Common Intermediate Language) под платформу .NET.Данный материал я решил разбить на две части из-за лени все сразу это описывать

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

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

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

Введение

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

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

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

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

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