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

Проблема в контроле. Я стал жестче и глубже контролировать код и… стал тратить на этот контроль слишком много ресурсов.

Основной принцип прост. Если контролю подлежит 10-20% случаев, то на контроль надо тратить… 0% ресурсов. Баги и переписывания всё равно будут. Но лучше разделить кодирование и отладку и на время кодирования об ошибках вообще забыть.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Продолжая свои «css-раскопки» возникла новая идея, разобрать по косточкам ещё одну актуальную тему, которая касается равномерного выравнивания блоков по ширине. В принципе мои доскональные исследования я уже запостил у себя в блоге, но так как прошлая моя работа очень понравились Хабра-сообществу, то я решил сделать здесь небольшой краткий обзорчик этой статьи, чтобы ни одна хабра-душа не пропустили её наверняка. Так что, как говорил Гагарин: «Поехали».

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

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

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

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

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

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

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

Как обнаружить, что база данных повреждена

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

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file 'D:\Develop\Databases\Broken1.mdf'.

Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816.

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

Доброго времени суток!

Введение

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

Так уж получилось, что последние пару лет я много работаю с кризисными проектами. Это проекты, в которых деньги потрачены, цели не достигнуты, все сроки много раз нарушены, менеджера уволили или он сам в ужасе сбежал, а уровень мотивации команды – ниже некуда. В общем, материализовавшийся fuck up. К сожалению, большинство таких проектов нельзя просто закрыть – все они важны для заказчика.

Доброго времени суток!

Введение

В своё время было необходимо сделать заметки в форме стикеров для веб-сайта. Как вы понимаете, выбора большого особо не было и мой выбор пал на всеми нам любимый CSS3. С его появлением осуществление задуманного стало возможным без какого-либо велосипедостроения. Итак, моё решение проблемы под катом. На самом деле, мопед не мой. Мне дали всего-лишь покататься.

Технология Windows Installer (MSI) является стандартом де-факто в мире системных администраторов, занимающихся распространением и поддержкой программного обеспечения для десктопных и серверных версий Windows. Формат MSI поддерживается всеми крупнейшими системами управления конфигурациями (Microsoft SCCM, CA Unicenter и многими другими), а для некоторых систем распространения ПО — является единственным поддерживаемым форматом.
Мой опыт работы с этой технологией — как теоретический, так и практический — приобретен за время работы в компании «Инфопульс Украина» и связан с созданием MSI-пакетов и подготовкой готовых MSI-пакетов к автоматической установке в корпоративной среде.

Облачный хостинг SkyDrive наконец-то дорос до нормального вида и хотя бы по функционалу способен конкурировать с Dropbox и Google Apps. По крайней мере, в таком виде его уже не стыдно рекомендовать знакомым. Сегодня утром разработчики выкатили новую версию SkyDrive и отчитались о сделанной работе.



Во-первых, в корне переделан интерфейс загрузки файлов на хостинг. Если раньше он был рассчитан на обмен файлами между пользователями Windows Live, то теперь нет никакой дискриминации. Пару щелчков мышкой — и вы отправляете ссылку на любой почтовый адрес, можно сразу опубликовать в Facebook. Или просто получаете URL, который можете сами передать адресату(-ам).

Однажды решив зарегистрироваться как ИП я столкнулся к несколькими неожиданными проблемами, о которых в интернете не могу найти практически никакой информации. Знакомая бухгалтер, консультирующая меня, тоже не слышала о подобных проблемах, поэтому решился на написание данного топика, чтобы помочь коллегам не попасть в подобную ситуацию.
Основные пункты «обязательной программы» регистрации много раз разжеваны в интернете, но пройдемся по ним заново, используя собственный опыт. Я специально не буду давать ссылки на программы, формы бланков и постановления, так как они быстро устаревают и смысла выкладывать их я не вижу. К тому же принятое заявление в Тамбове, могут не принять в другой налоговой и т.д.
Еще в моем случае нет наемных работников, это важно для прохождения «квеста».

Нам в Эльбе довольно часто задают вопросы по типу «Я „упрощёнщик“, у меня есть электронный кошелёк в Яндекс.Деньгах, как его в доходах-расходах учитывать и перед налоговой отчитаться?».

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

Page Visibility API — новое API в JavaScript, которое позволяет узнать, видит ли пользователь ваш сайт или же он, например, открыл другой таб.

Каким образом это API может сделать наш Веб дружелюбнее и уютнее? Ну самое очевидное:

• Сделать сайт более дружелюбным к пользователю, «поднять юзабилити». Например, отключать слайдшоу или ставить видео на паузу, когда вы переключаетесь в другой таб (например, вы смотрите видео на YouTube и вам приходит срочное эл. письмо).
• Не потреблять лишних ресурсов. Выключать лишнюю логику, когда она не нужна, так как пользователь не видит сайт. Например, в фоновом табе отключать сложные JS-рассчёты или реже проверять новые сообщения по AJAX.
• Считать более точную статистику. Например, не засчитывать пользователей, которые открыли ваш сайт в новом табе и закрыли его не просматривая.
• Поддерживать новую технологию пререндеринга из Google Chrome, когда браузеру заранее загружает и рендерит указанную страницу, чтобы открыть её мгновенно. Например, в поиске Google первый результат выдачи будет отмечен на прередеринг.
• Сделать эмулятор кота Шрёдингера (на иллюстрации), который отобразит живого или мёртвого кота только тогда, когда пользователь откроет загруженный в фоне таб.

Чтобы сделать работу с Page Visibility API более удобной, я (во славу Злых марсиан) разработал библиотеку Visibility.js. Она позволяет забыть о вендорных префиксах и добавляет «сахара» высокоуровневых функций, чтобы писать короткий чистый код (например, Visibility.every — аналог setInterval, но работает только, если сайт в открытом табе).

Милый пример видео-проигрывателя, который останавливает видео, когда страница становится невидимой (открывать в Google Chrome 13).

На примере хранения дерева комментариев.

Многие наверняка сталкивались с проблемой хранения комментариев, по крайней мере задумывались об этом. Очевидным решением «в лоб» является ссылка на родительский комментарий и, как следствие, рекурсивные вызовы при необходимости отобразить дерево. Современные СУБД поддерживают иерархические запросы, но мне кажется, что это просто перенос проблемы за пределы области видимости, может быть я не прав. В любом случае я писал для Google Application Engine, там разговора об иерархических запросах не идёт вообще.

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

Я наступил на все грабли подбора персонала в своей прошлой компании и теперь знаю, что и как можно делать лучше. Делюсь, тем более, что на Хабре про то, как всё это крутится у нас, неоднократно спрашивали.

Вкратце:

• Хотят сотрудники работать по умолчанию или нет?
• Почему авторитарные лидеры вымирают.
• Насколько важно распространение информации (менеджмент «открытых книг»).
• Кто не косячит – тот не работает.
• Как мы собеседуем.
• Как мотивировать команду.
• О рандомных премиях.
• Корпоративы: может, лучше дать всем по $100?

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

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

Здравствуйте, хабраюзеры!

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

В работе первые 90% проекта делаются за 10% времени, оставшиеся 10% — за 90%
Народная мудрость

В работе очень важным является доведение до конца.

Существует всего одно результативное состояние у задачи — «сделано». Все остальные — почти, еще чуть-чуть, немного осталось, сделал наполовину, и т.д. — это состояние, которое я называю «не сделано».

Согласно одной статистике, 4-5% людей обладают талантом предпринимателя (от слова «предпринимать»). Думаю, не сильно больше — талантом доводить до конца.

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

Бороться до конца — вот кредо настоящего профессионала (умение резко переключиться под нужды, ясное дело, также нужно:).

Теперь пример доведения дела до конца в рамках целого проекта.

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

Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы.