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

• Убедитесь, что срок действительно жесткий
• Не берите на себя проекты с нереальными сроками
• Планируйте методом «набегающей волны»
• Периодически пересматривайте оценку проекта
• Оценивайте проект эмпирически
• Привлекайте к первоначальной оценке команду

Всем добрый день.

Недавно я задумался надо вопросом фонового обновления информации и мне пришла в голову одна идея.

Суть задачи — мы находимся на странице списка новостей. Необходимо обновлять список по мере поступления новых новостей. Серверный язык PHP

Фэйлом кончаются от 30% до 50% попыток внедрить штатную интеграцию сайта с 1С. Это коллеги рассказали, у меня-то в бизнес-плане заложено 75%. То есть, в трех случаях из четырех — придется что-то подкручивать напильником, а в одном — вообще вызывать эвакуатор или реанимацию. И чего бы это, ведь…

… Топовые производители современных отечественных систем управления в один голос заявляют, что умеют интегрироваться с 1С. Естественно, это касается по большей части типовых конфигураций — всего не предусмотришь, ага. Да и маркетинг заставляет говорить, что «это просто!». Слоган, который, наверное, никогда не умрет.

Рассмотрим процесс интеграции с точки зрения клиент-исполнитель. Сценарий продажи может превратиться в сущий адъ из-за пары неловких движений менеджера.



Так что знакомимся с горьким опытом и делимся своим:

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

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

flotr2 — это библиотека с открытым кодом для построения HTML5 графиков и диаграмм. Flotr2 — так как стала ответвлением от Flotr, но уже без привязки к Prototype JS и с множеством усовершенствований.

Хочу представить вам новый профессиональный инструмент для веб-разработки под Windows.

Open Server — это портативный локальный WAMP/WNMP сервер, имеющий многофункциональную управляющую программу и большой выбор подключаемых компонентов. Представленный пакет программ не является очередной любительской сборкой собранной «на коленке», это первый полноценный профессиональный инструмент, созданный специально для веб-разработчиков с учётом их рекомендаций и пожеланий.

Если вы всё еще используете Denwer, Xampp, Vertrigo и т.д. или предпочитаете устанавливать все компоненты сервера раздельно — добро пожаловать под кат.

CSS3 видели и пробовали все, кого он мог заинтересовать. И закругленные уголки и падающие тени мы уже можем генерировать без лишнего труда.

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

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

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

В этой статье я расскажу о трех типах instances в Amazon с примерами подсчета стоимости и скринами с консоли и биллинга Amazon. Статья родилась в силу малого количества информации про amazon web services, в частности данных про экономию оплаты на reserved instances я не нашел в рунете. Много скринов для лучшего понимания, когда я начинал работать с amazon мне этого сильно не хватало.

Многие знают, что Amazon предоставляет возможность автоматически наращивать мощность вашего пула (увеличивать количество виртуальных серверов) в зависимости от нагрузки. Однако я не сумел найти в русскоязычном сегменте сети толкового описания практической реализации такой схемы. Рискну представить на суд общественности итог моих штудий на данную тему.

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

У каждой задачи есть несколько вариантов решения. И иногда в угоду скорости приходится выбирать не самый красивый, зато работающий и выполняющий поставленные перед ним цели. Итак, в один не очень прекрасный день возникла необходимость реализовать следующую функцию: у каждой (почти) страницы сайта должны быть автоматически сгенерированные копии в форматах DOC и PDF. С сохранением всех таблиц и картинок внутри контента. И если с PDF всё относительно просто (tcpdf наш друг и брат), то с DOC'ом возникла морока. Под катом — пример решения данной задачи.

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

Особо вероятно изобретение велосипеда, когда рост сложности приложения происходит постепенно и в некотором смысле незаметно. Сложное приложение обычно является богатым приложением (rich), его элементы и особенности специфицированы W3C www.w3.org/TR/backplane. Известный JavaScript-евангелист Addy Osmani так дополнительно определяет сложное приложение: “По-моему, крупное JavaScript приложение есть нетривиальное приложение, требующее значительных усилий разработчика для поддержки, причем наиболее сложное оперирование обработкой и отображением данных ложится на браузер” (http://addyosmani.com/largescalejavascript/).

Вчера Karl Seguin – автор книги The Little MongoDB Book, которую часто рекомендуют для быстрого старта с MongoDB, опубликовал аналогичное руководство для Redis под названием The Little Redis Book (при участии Perry Neal). Книга состоит из 29 страниц, написанных за 2 коротких дня с использованием Markdown. Исходная разметка книги находится на GitHub. Сама книга распространяется свободно под лицензией Attribution-NonCommercial 3.0 Unported license.

Содержание книги

• About This Book
• Introduction
• Chapter 1 — The Basics
• Chapter 2 — The Data Structures
• Chapter 3 — Leveraging Data Structures
• Chapter 4 — Beyond The Data Structures
• Chapter 5 — Administration
• Conclusion

Скачать

The Little Redis Book (PDF)

Короткий ответ

ITSM – Information Technology Service Management

Чуть более длинный ответ

ITSM – это область знаний об управлении деятельностью по оказанию ИТ-услуг. Основных исходных посылок, принятых в ITSM, две: во-первых, услуга – это основная форма предоставления ценности, исходящей от ИТ, во-вторых, деятельность по оказанию ИТ-услуг лучше всего организовать как комплекс процессов с четко определенным целями, задачами, ролями и обязанностями.

ещё более полный ответ под катом

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

Основанный на трансформациях и переходах CSS3, javascript-фреймворк для создания презентаций impress.js выходит за рамки понятия “слайд” и позволяет строить презентации в открытом, неограниченном трёхмерном пространстве. Источником вдохновения для него послужил сервис prezi.com. Репозиторий impress.js на Гитхабе появился меньше месяца назад, но уже стал одним из самых популярных. Нетерпеливые могут посмотреть небольшую демку здесь, а остальные — создать пример необычной презентации прямо сейчас.

Способов хостинга mercurial репозиториев достаточно, но я сочинил именно такой вариант по следующим причинам:

1. nginx: мало кушает, быстро работает — скорость
2. supervisor: мониторит процесс, перезапускает если что — надёжность
3. gunicorn: wsgi, большие возможности по настройке — эффективность

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

Если вас заинтересовала тема, то конкретные инструкции и конфиги — под катом.

Низкий поклон Хабранароду!

Предисловие

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

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

Я хочу описать простой минималистский подход к разработке сложных JavaScript приложений. Из внешних библиотек будут использоваться только jQuery и мой js-шаблонизатор, причём из jQuery используются только $.ready(), $.ajax() и $.proxy() — т.е. суть не в библиотеках (их тривиально заменить на предпочитаемые вами), а в самом подходе.

В основе подхода лежат две идеи:

1. JavaScript виджеты — небольшие модули, каждый из которых «владеет» определённой частью веб-странички (т.е. всё управление этой частью странички происходит исключительно через методы этого модуля, а не через прямую модификацию DOM — инкапсуляция). Виджет отвечает исключительно за функциональность, но не за внешний вид; поэтому прямая модификация части DOM, которым «владеет» виджет, снаружи виджета допускается — но только для чисто дизайнерских задач (для архитектуры и общей сложности приложения нет принципиальной разницы между коррекцией внешнего вида через CSS или jQuery).
2. Глобальный диспетчер событий. Взаимодействие между виджетами осуществляется путём посылки сообщений глобальному диспетчеру (слабая связанность, паттерн Mediator/Посредник), а уже он принимает решение что с этим сообщением делать — создать/удалить виджеты, дёрнуть методы других виджетов, выполнить дизайнерский код, etc. В отличие от динамического подхода к обработке событий (когда обработчики конкретного события добавляются/удаляются в процессе работы) статический диспетчер сильно упрощает понимание и отладку кода. Безусловно, есть задачи, для которых нужны именно динамические обработчики событий, но в большинстве случаев это избыточное усложнение, поэтому всё, что можно, делается статическими обработчиками.

Известно, что следуя идеям старой школы, а именно, добавляя ссылки на JS и CSS в страницы, может обернуться большим временем загрузки страницы. Браузер отображает страницу по мере скачивания, но останавливается, если натыкается на тег script со ссылкой, до того момента, пока скрипт не будет загружен и выполнен. Сайты стали использовать всё большее количество скриптов, начальное отображение страницы занимает всё больше времени, к примеру, на этой странице, которую вы читаете, 13 скриптов, 7 из которых находятся в head'е. Ко всему прочему, некоторые браузеры по-прежнему придерживаются ограничений на одновременное количество загрузок с одного хоста.

Сразу предлагаю принять, что все JS файлы минимизированы, и передаются в сжатом виде.

Существует несколько решений, как то:
— поместить стили и скрипты прямо в страницу;
— установка аттрибутов async/defer тегу script;
— склеить все скрипты в один файл;
— помесить ссылки на скрипты в конец body;
— разместить все файлы на CDN/на разных хостах;
— свой вариант…

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

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

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

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

Ну, от слов к делу