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

Забавно лишь, что вся эта белиберда под катом родилась в уме Кодда еще до возникновения SQL как языка, а теперь вот в терминах SQL все подавай…


Что же такое вторая нормальная форма или 2NF? Так чтоб трехлетний ребенок действительно понял…
Для начала разберемся в целях, которые преследует нормализация. Под катом нету терминов дискретки…

На написание данной статьи меня подтолкнул топик HTML в PDF, правда по причине того, что он посвящен языку php, лично мне он был мало полезен, т.к. весь опыт работы с php у меня сводился в переводе нескольких скриптов на C#, поэтому я решил сделать небольшой обзор того, что доступно для работы с pdf по средствам языка C#.

Ко мне в список попало 7 библиотек, о которых я скажу несколько слов, а для самой популярной (судя по ответам на stackoverflow), я напишу, как с помощью неё сделать простейший документ. Сразу скажу, что это iTextSharp и работа с ней будет описана в конце статьи.

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

А нужны ли нам вообще команды?

Работа в одиночку

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

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

При работе в команде все не так радужно, не так ли? Внезапно, вам приходится посещать совещания. Вам приходится участвовать в различных дискуссиях на технические темы (что еще ничего), а также на другие неинтересные и скучные темы. Вам приходится отвечать на вопросы, хотя бы из вежливости, а также частенько делать вещи, с которыми вы совершенно несогласны.

Так зачем же люди формируют команды?

Один из самых частых ответов на вопрос «Почему я не пишу юнит-тесты» — это вопрос «А кто напишет тесты для моих тестов? Где гарантия, что в моих тестах тоже не будет ошибки?», что свидетельствует о серьёзном недопонимании сути юнит-тестов.

Цель этой заметки — коротко и чётко зафиксировать этот момент, чтобы больше не возникало разногласий.

Итак, юнит-тест — это

Знание английского для ИТ специалиста — это одно из важнейших профессиональных качеств. Поэтому процесс изучения английского языка должен быть непрерывным. Для изучения рекомендую сайт Common Errors in English Usage, где собрано много типичных ошибок использования различных слов и выражений.

Более 7 лет назад в 2003 году компания Parking.ru принимала участие в создании первой версии WebMatrix Hosting. Проект оказался очень популярным и беспрецедентным по своим масштабам.

И вот недавно была анонсирована новая версия проекта WebMatrix и мы снова не остались в стороне и объявляем о запуске проекта WebMatrixHosting.ru.

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

Прелюдия

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

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

Кто здесь?

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

11:24:21 PM Michael: ну хз, надо пробовать
11:24:24 PM Michael: наверное так лучше
11:24:27 PM Michael: даже я думаю наверняка
11:24:36 PM Michael: но пока меня че-то останавливает
11:24:38 PM Michael: лень наверное :)

Знакомо? «Не хочется разбираться? Нет времени?» Тогда читаем дальше. В статье расскажу, как настроить свое любимое рельсовое окружении на разработку с подходом BDD и начать новую жизнь (опционально).

Как-то раз в одной неглупой статье один неглупый хабраюзер рассказал одну неглупую идею. Суть её была в том, что в его компании настроена система, контролирующая написанный программистами код в момент попытки добавления его в репозиторий и отклоняющая код, не проходящий по некоторым критериям. Мне идея понравилась. Я (и еще 3 человека) попросили автора развить мысль и написать статью об этом, но она так и не появилась. И я решил разобраться сам.

Всем привет!

Всё ближе и ближе новый 2011 год кролика! По этому случаю мы приготовили небольшое обновление LinguaRabbit LinguaLeo.

• Для визуалов — возможность добавлять ко всем новым словам картинки-ассоциации в личном словаре.
• Для аудиалов — автоматическое произношение всех слов при прохождении тренировок.
• А для 2011 человек, изучающих английский язык (first come, first served) — небольшой новогодний презент.

Узнать подробности и получить подарок может любой желающий, используя лео-код, спрятанный под катом.

В топике блиц-обзор книг, которые будут полезны IT-специалистам, бизнесменам и тем, кто собирается открыть своё дело. Рядом с каждой — короткие пояснения, почему и зачем стоит прочесть.

Отобраны лучшие 10% из примерно 200 прочитанных книг о маркетинге, продажах и всем связанном — самые «пробивные» вещи, которые помогут вам не тратить время на всякий шлак, а сразу начать с главного.

В конце — суммация книг, которые хабровчане рекомендуют в комментариях помимо основного списка.

Друзья, вы давно вставали с компьютерного кресла и разминали затекшие конечности? Сидячая работа способна неслабо подкосить здоровье — лишний вес приводит к ожирению, сахарному диабету и сердечно-сосудистым заболеваниям… И проблема эта носит планетарные масштабы — более 30% процентов населения Земли страдает от лишенго веса, а это 1,7 миллиарда человек. С этим необходимо что-то делать, и желательно эффективно и быстро.
Ответы на вопросы находятся в плоскости спорта и рационального питания — но в самих этих сферах пока вопросов больше, чем ответов.

Поэтому мы решили создать Gipis — сервис, который позволит решить эти проблемы.

Топик навеян впечатлениями от докладов на swpiter и постом о том, как не продать машину :)

Как работать над стартапом и всегда оставаться в выигрыше?

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

Картинка слева кликабельна, а ниже — текстовое описание в 12 шагах как инициировать стартап и при этом всегда оставаться в выигрыше.

1. Идея!

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

Самое важное в идее — это не терять мотивацию вплоть до 10 шага и тогда вы в любом случае получите для себя выгоду.

2. Детализация идеи

Необходимо хотя бы примерно ответить на эти вопросы:

• область применения
• какие задачи поможет решить
• какие инструменты применяются для решения задач
• что вы хотите получить в процессе и в результате реализации
• какие-то существенные моменты, которые вам просто необходимо изложить, чтобы не потерять в будущем

На этом этапе ещё рано отвечать на вопросы:

• сколько времени вы можете уделить (если идея вас реально интересует, вы перейдёте к следующим этапам)
• сколько на это нужно денег
• кто вам ещё нужен для реализации идеи

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

Итак, джентльмены, прошу минуточку внимания!

В последнее время, обсуждая какие-нибудь технологические или архитектурные штукенции, в спорах приходилось частенько упоминать, что «это же просто opinion», и давать ссылку на статью из Getting Real под названием Make Opinionated Software (по ссылке можно не ходить, ниже перевод той самой статьи).

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

В свое время тоже (и не раз) пройдя испытания в велосипедостроении, я уже давно придерживаюсь того же мнения, что и «37 сигналов». И они говорят нам:

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

В классическом DDD нужно выделить домен – совокупность объектов и их связей. Но когда я применял этот принцип в жизни, встретился с двумя трудностями:

1. Если есть большой домен и кучка сервисов вокруг него, то становится сложным управление доступом к членам класса. Выглядит это так: есть объект User со свойством CreatedAt, которое я хочу разрешить редактировать только сервису MembershipService. Чтож, пишем InternalsVisibleTo с указанием MembershipService. Дальше нам нужно сделать объект, например Car, у которого есть свойство PassedDistance, которое я хочу открыть только для CarService. Опять повторяем манипуляции с InternalsVisibleTo, но тут появляется проблема: теперь Membersip может изменять километраж автомобиля, а CarService – дату регистрации пользователя.
2. DDD всё еще не дает возможности строить приложение «по кирпичикам» – просто подключая нужные модули. Говорят, что в Ruby можно, поэтому хочется такой же легкости в .Net =). А не получается всё по той же причине – домен выделен в отдельную сборку, и, подключая сервис, приходится вручную тянуть из домена все зависимые сущности, перебирая их свойства, т.к. большинство из них в новом проекте не понадобятся. Т.е. проблему связанности сервисов DDD решает, а вот связанность домена всё еще не решена.

Выход один

Смотреть всё подряд
Представлены доклады:

1. Ruby NoName Podcast Crew «Chef Light»
С помощью Chef можно организовать управление серверами не только для больших организаций, а для всех.
Есть сервер, есть клиенты которые гоняются на других серверах. Сервер говорит что надо сделать, клиенты делают. Для всего этого существуют dsl конфигурации с поддержкой pakages.
*Удалённое проведение конференции накладывает свои особенности. Извиняемся за качество видео.

2. Макс Лапшин «Rails do scale»
Пример приложения быстрого приложения на Rail для Vkontakte с посещаемостью ~ 1000 запросов в секунду.
Дёшево и работоспособно.

3. Алекс Дмитриев «Умное кэширование в rails»
Докладчик рассказывает о том, как пользоваться кэшированием в Rails, когда нужно использовать кэширование, что кэшировать, где хранить кэш и т.д.

4. Иван Евтухович «Vim or die»
Докладчик рассказывает о возможностях Vim — одного из мощнейших текстовых редакторов с полной свободой настройки и автоматизации.

5. Тимофей Цветков «Liquor, Liquid и другие безопасные языки разметки в RoR»
Безопасные шаблонизаторы для RoR. С помощью чего и как.

6. Андрей Руденко «Deploy fu»
Докладчик обсуждает достоинства и недостатки наиболее популярных в Ruby-сообществе инструментов развертывания приложений: Chef, Capistrano, Puppet, Сfengine, Bash-скриптики и др. Основная часть доклада посвящена презентации своего решения — Lorenz (см. github->lorenz).

Приятного просмотра.

«Если единственный язык, который вы знаете — это Java или C#, я не думаю, что вы профессиональный программист — вы как молодой плотник, который пока работал только с одним видом дерева.»
Дядя Боб

Несколько месяцев назад я начал разрабатывать приложения для iPhone. Переключение с платформы .NET и C# на Cocoa и Objective-C проходило не без приключений, но было достаточно интересным и познавательным. Скоро мне предстоит помогать осваивать новую платформу и другим разработчикам нашей компании. Поэтому решил написать серию вводных заметок, которые, надеюсь, сделают этот переход более плавным.

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

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

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

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