Ценность материала в том, что:

1) это хороший способ взглянуть на себя со стороны огромному числу программистов PHP, так как общая средняя квалификация этого класса программистов значительно ниже среднего по другим более серьезным языкам; взгляд со стороны поможет понять свои проблемы и найти способы их преодоления;

2) конкретные советы о том, что следует почитать/посмотреть.

Ссылка на материал: Как стать хорошим программистом и хорошим php-программистом в частности?

А ниже позволю себе сделать частичный копипаст предложенных решений.

Мастерство программирования (или скорее можно назвать Основы)

• Совершенный код,
• Чистый код,
• Рефакторинг,
• Программист-прагматик,
• Архитектура корпоративных программных приложений,
• Кодеры за работой.

Нашел очень хорошую и исчерпывающую статью на английском: How to be a Programmer: A Short, Comprehensive, and Personal Summary

Курсы, выложенные по MIT OCW:

• MIT Electrical Engineering and Computer Science

Курсы Стэнфорда:

• Mashine learning
• Natural Language Processing class
• Software Engineering for Software as a Service class

На каждом сайте внизу есть ссылки на другие курсы Стэнфорда.

Алгоритмы.

Как развивать:

Искусство программирования Кнутта — читать и выполнять задания.

Project Euer — задания по алгоритмам, можно писать на PHP.

ООП и Шаблоны проектирования

PHP: объекты, шаблоны и методики программирования М. Зандстра сейчас, наверное, лучшая книга для введения в шаблоны проектирвания для PHP.

Head First Design Patterns, на русском Паттерны проектирования — очень рекоммендуют, как очень хорошо разъясняющую книгу.

какие книги, методы обучения, задачи порекоммендуете?

PHP основы

Как развивать:

собственно работа по профессии и набор опыта,

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

Потом есть stackoverflow, там введи в поиск ~php~ и читай вопрос, давай свой ответ (про себя), потом смотри, что другие написали. Будешь по тегам смотреть заодно, что пхп-ники изучают.

Javascript Основы

Как развивать:

собственно работа по профессии и набор опыта,

JavaScript. Подробное руководство. Д. Флэнаган (читать и разбираться в пропущенных основах – типы, обьектная модель и др.)

JavaScript: The Good Parts

JavaScript. Шаблоны

Источник: Как стать хорошим программистом и хорошим php-программистом в частности? Ни автор, ни комментаторы не имеют ко мне никакого отношения.

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

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

Хочется поехать на рынок и купить новой одежды? Значит, хочется созидать. Хочется программировать? Это также желание созидания. А вот если появилось желание почитать книгу или какие0нибудь статьи, «полистать» интернет, пообщаться с друзьями, то можно говорить о желаниях потребления.

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

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

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

Обычно периоды потребления и созидания примерно равны по времени между собой и следуют один за другим попеременно, как полоски на зебре. Длина периодов зависит от разных обстоятельств, в том числе разнится во время разных жизненных этапов. Сейчас у меня эти периоды могут измеряться неделями, но, как правило, не больше 2-3 месяцев. Мне кажется, что раньше (в юности) они измерялись днями.

Между этими периодами есть короткий срок, который представляет собой неопределенность. В это время нет явных желаний ни на потребление, ни на созидание. Либо не хочется вообще ничего, либо всего, но понемногу. Состояние в это время может становиться депрессивным. Этот период можно назвать «ломкой».

Все это напоминает всем известные биоритмы. Я никогда не вникал в эту тему и для меня слово «биоритм» ассоциируется только с графиком (ко)синусоиды, и все. Есть подозрение, что я для себя как раз и открыл биоритмы. Пока не знаю.

Все описанное выше можно изобразить на графике:

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

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

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

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

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

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

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

Все предложения хостинга можно разделить на 4 группы: Shared hosting (общий сервер), VPS (virtual private server — частный виртуальный сервер), Dedicated (выделенный сервер) и Cloud (облачный хостинг). Colocation (размещение сервера) в расчет не берется, так как это просто аренда места в стойке, а не хостинг.

Итак, с чем же можно провести аналогию?

Первое, что пришло в голову — ресторан. Shared — небольшой стол, заполненный едой, а вокруг стоя тянет руки толпа студентов. VPS — типичный ресторанный стол, у каждого своя еда на тарелке, присутствует малая группа людей. Dedicated — один за столом. Cloud — вот тут самое интересное. Толком придумать идею не получилось. Если у кого получится, велкам в комменты.

Чтобы восстановить пробел с Cloud, решил перенести фокус со стола на одну емкость — стакан. Shared — стакан с жидкостью забит трубочками. VPS — стакан перегородками поделен на 4 равные части, в каждой части своя трубочка. Dedicated — одна трубочка в стакане. Cloud — система стаканов, соединенных трубочками. К этой системе равномерно подключаются трубочки «клиентов».

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

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

Решение. В консоли выполняем следующие команды:

$ sudo modprobe -r psmouse
$ sudo modprobe psmouse proto=imps

Заработал скрол? У меня — да. Если у вас тоже, по результат надо закрепить. Для этого открываем /etc/modprobe.d/options и добавляем туда строку.

sudo gedit /etc/modprobe.d/options

Строка:

options psmouse proto=imps

Теперь и после ребута скрол останется работать.

P.S. Печальные последствия такого способа заключаются в том, что из настроек мыши пропадает вкладка Touchpad.

Решение отсюда: http://superuser.com/questions/136568/get-back-the-touchpad-scrolling-missing-in-kubuntu-10-04

Если взять одного из ведущих российских облачных хостеров — selectel.ru, у которого самая низкая стоимость за Гб/час хранения данных (0,005 р), то месяц хранения бэкапов будет стоить 360—540 рублей в месяц. Это около $15. Много. При этом, платить надо еще за трафик и работу виртуальной машины во время синхронизации.

Рассмотрим сервис хранения файлов от Amazon. До терабайта там цена от $0.093 за Гб. Для хранения моих бэкапов понадобится от $9,3—14. Это поменьше, но там нет виртуальной машины, а значит сложнее синхронизация.

Для сравнения посмотрим на Dropbox. Мы знаем, что он хранит пользовательские данные на Amazon S3. Значит, не должно быть дешевле, чем в расчетах Амазона. Аккаунт Pro (100 Гб) стоит $20 в месяц. Да, дороже более чем в 2 раза.

Может Ubuntu One? 20 Гб у них стоят $3. Значит я заплачу примерно $14—22. Тоже дорого…

Стоимость внешних HDD от 250 Гб начинается от $55. Хоть надежность такого бэкапа будет гораздо ниже, чем в случае облаков, да и возни больше (ведь нельзя хранить винчестер в той же локации, где и сервер; а значит нужно либо носить его туда-сюда, либо договариваться с кем-то о бэкапах через интернет). Зато цена приятная: даже по Амазону наш HDD окупится через 6 месяцев.

Во всех расчетах не учитывались затраты на трафик. При первой синхронизации они будут велики ($10—20 для облаков), но при последующих синхронизациях они будут относительно небольшими (трудно подсчитать, ну пусть будет $1—2 в мес.). Для внешнего HDD затрат на первый слив не будет.

Есть также сервис, специализирующиеся на бэкапе в облака. Гуглятся по запросу «cloud backup». Я несколько штук посмотрел, но цен ниже $15 в месяц за 100 Гб не видел. Только больше.

Чтобы попасть в список Labs, нужно зайти в Google Maps и нажать на шестеренку в правом верхнем углу. В выпадающем меню выбрать «Maps Labs».

Откроется окно со списком, где можно включить/отключить ту или иную фичу.

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

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

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

Тестовое задание сходу дают не все, а вот резюме читают, пожалуй, все работодатели. В зависимости от конъюнктуры рынка (отношения спроса к предложению) на этапе просмотра резюме отсеиваются до 90 % соискателей. У меня нет точных среднестатистических данных, но эмпирически рискну предположить, что в среднем отсеиваются 60—70% соискателей.

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

Выходит, что всем выгодно, когда резюме составлено хорошо. А что значит хорошо? Это значит, что соискатель хорошо подаст все свои навыки, опыт и преимущества перед конкурентами, а работодатель получить всю первичную интересующую его информацию о кандидате.

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

Я постоянно участвую в поиске веб-разработчиков и за последнее время видел много разных резюме. Что особенно важно, приглашая людей на собеседование практически всегда связь между стилем написания резюме и результатами оценки кандидата прослеживается очень хорошо. Хорошее, подробное резюме с информацией по делу — кандидат хороший. Куча воды, названий технологий, но отсутствие четкой информации по опыту работы — кандидат «ниочем».

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

С позиции работодателя расскажу о своем видении резюме веб-разработчика. Язык программирования при этом значения не имеет.

От соискателя в резюме важно получить следующую информацию:

1. минимальную информацию о себе, как о личности;
2. краткую информацию об образовании;
3. подробную информацию о предыдущих местах работы;
4. подробную информацию о навыках и опыте соискателя в контексте вакансии (позиции, должности).

Эти четыре пункта обычно содержит любое резюме по любой специальности. И на этом уровне оно стандартное. А вот какую информацию нужно писать по этим пунктам и как ее преподнести? Это уже позиционно-уникально.

1) Коротко о себе
Таблица или список со следующими строками. Все строки обязательны. Приложенная фотография является плюсом, т.к. психологически предполагает более серьезное восприятие резюме работодателем.

1.1) ФИО (отсюда станет ясен пол, так что писать нужно полностью)
1.2) Год рождения (или возраст, если резюме рассчитано на короткий период)
1.3) Город (место жительства, адрес не нужен)
1.4) Семья (брак, дети)
1.5) Образование (высшее/среднее/базовое или др.)
1.6) Отношение с армией (не обязательно писать, но все равно об этом спросят)
1.7) Иностранные языки (перечислить языки с указанием уровня влядения; не стоит тут писать русский, украинский или белорусский)
1.8) Позиция (должность; в одной организации может быть несколько вакансий, к которым подойдет ваше резюме, поэтому указать позицию или позиции, на которые претендует соискатель, нужно обязательно)
1.10) Желаемая заработная плата (реальная заработная плата, на которую нацелен соискатель в настоящее время; это очень важная для работодателя информация, и если соискатель знает, что он хочет, нужно обязательно указать, если не знает — на это укажет отсутствие данной информации; можно писать в стиле «от Х»)

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

2.1) Учебное заведение
2.2) Факультет
2.3) Специальность
2.4) Годы обучения (лучше указать время начала и окончания обучения, т.к. иногда возникают непонятные ситуации, когда указан только один год)
2.5) Окончен ли успешно? (если обучение прервано, об этом обязательно нужно написать отдельно)

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

3.1) Название компании (так, как оно пишется «в миру»)
3.2) Сколько человек в организации/подразделении (опционально, если компания неизвестная, просто поможет оценить ее масштаб)
3.3) Должность (позиция, так, как она называлась в компании; можно дополнить общепринятым названием позиции, если оно отличается от принятого в компании)
3.4) Время работы (лучше всего в формате мм.гггг — мм.гггг / н.в.)
3.5) Обязанности (тезисно: что реально входило в круг обязанностей, пояснения и комментарии будут уместны)
3.6) Сколько человек в подчинении (если были люди в подчинении, об этом обязательно стоит упомянуть, иначе — пропускается пункт — 0 писать не нужно)
3.7) Проекты (это отдельный список проектов, в которых соискатель принимал участие в компании; если подход не проектный или если нет желания все расписывать, можно просто описать в текстовом виде, что соискатель сделал, работая в компании)
3.7.1) Название проекта с кратким описанием (из этого должно быть понятно, какие разработки велись в рамках проекта)
3.7.2) Временные рамки участия в проекте
3.7.3) Результаты (как личные, так и общие)
3.8) Причина ухода (если указывать желания нет, не надо, но все равно скорее всего на собеседовании спросят)

4) Технологии
Очень важный блок. Из него должно стать понятно, каким навыками соискатель владеет, с какими технологиями имел опыт работы и какой этот опыт, как соискатель оценивает свои знания. Информация обычно подается в табличном виде с колонками: название технологии, оценка своего уровня (по любой шкале, но не менее чем из 3-х уровней: начальный, средний, продвинутый), сколько лет опыта.
Здесь нужно писать только то, что уместно в контексте позиции. Не стоит указывать технологии, по которым уровень соискателя такой, который не позволит применение технологии на практике без дополнительного обучения. Информация разбивается на отдельные группы:

4.1) Языки программирования, разметки, запросов и т.д. (т.е. все, что является языком чего-либо или близко к этому)
4.2) Фрэймворки и библиотеки (стоит указывать только общеизвестные; нет смысла указывать самостоятельно разработанные библиотеки и фрэймворки, если ими пользуется только сам соискатель или его [бывшие] коллеги)
4.3) Технологии (то, что не является языком или библиотекой, но существует как стандартизированная и/или общеизвестная технология: AJAX, Web Services (SOAP), COM/OLE и т.д.)
4.4) Операционные системы (если у соискателя в арсенале опыт работы только с несколькими версиями Windows, этот пункт лучше вообще опустить; он имеет смысл, когда есть опыт работы с 2-мя и более разными ОС; версии одной и той же ОС лучше объединить в одну строку; разные дистрибутивы Linux/BSD/UNIX = разные ОС; необходимо указание уровня: администрирование сервера, либо использование в качестве десктопа)
4.5) Прикладное программное обеспечение (IDE, ПО для проектирования, разработки, тестирования, специфичное для специальности; не стоит сюда писать программы общего назначения, такие как Total Commander, FAR,  MS Office, gedit и т.д.)
4.7) Другое (если есть еще что-то важное, о чем соискателю хочется рассказать, следует это сделать)

Резюме лучше всего распространять в формате PDF. Если в качестве формата все же выбран Microsoft Word, то это должен быть формат DOC не выше версии Word 2003. Категорически не рекомендуется размещать резюме прямо в письме или в текстовом файле. Лучше сделать вложение к письму (не стоит размещать ссылку на скачивание резюме). Невыполнение этих требований говорит о неуважении к работодателю и вызывает аналогичное отношение к соискателю.

В моей практике был случай, когда в ответ на вакансию я получил письмо следующего содержания: «Здравствуйте. Слать резюме надоело, поэтому не буду. Если у вас действительно есть сложные задачи и хорошо поставлен рабочий процесс, звоните +37529…..». Сомневаюсь, что с таким подходом человеку удастся найти работу. Естественно, это письмо я проигнорировал. Через несколько дней этот человек перезвонил по телефону. Конечно, стоило сразу сообщить ему, что даже разговаривать с ним нет желания. Но я этого не сделал, и постарался более-менее вежливо с ним поговорить. Через пару минут разговор был закончен по смыслу тем, что он нам не подходит.

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

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

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

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

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

Факторный анализ места работы для разработчика ПО

1. Интерес
   • Проект
     • тематика
     • технологии
     • уровень сложности
     • нагрузки в продакшане
   • Зона ответственности
     • разброс обязанностей
     • принятие решений
   • Подчиненные
     • количество
     • качество
   • Заказчик
     • локальность
     • культурные различия
     • требовательность
2. Условия труда
   • Офис
     • эстетика
     • расположение
     • размер, оформление  комнаты и ключевых узлов
     • вентиляция и кондиционирование
     • ремонт (состояние)
     • стоянка
   • Рабочее место
     • компьютер
     • монитор
     • админские права и ограничения по ОС/ПО
     • интернет и ограничения
     • стол, стул
     • освещение
   • Коллеги и руководство
     • размер команды
     • адекватность руководителя
     • простота административной структуры
     • постановка работы команды
   • График
     • время работы
     • гибкость графика
     • отработки
3. Оплата
   • Зарплата
     • сумма
     • валюта
     • рост
   • Социальные вопросы
     • социальный пакет
     • корпоративы
   • Проблемы
     • задержки зарплаты
     • штрафы
     • ограничения контракта

Оценка по каждому фактору:

• 0 — нейтрально, нормально,
• ­­−1 — плохо,
• +1 — хорошо.

Проставляется оценка по каждому фактору 3-го порядка. Важно понимать, что оценка +1 всегда обозначает, что по данному вопросу обстоятельства в вашу пользу. Не важно как называется фактор: «уровень зарплаты» или «штрафы», +1 всегда будет обозначать, что по этому фактору вы в положении «хорошо» для себя. Соответственно −1 — значит «плохо» для вас.

Оценки суммируются по группам — факторам 1-го порядка. Каждому фактору 1-го порядка выставляется субъективный вес, который приводится к коэффициентам. Например, устанавливаются веса: «Интерес» — 10, «Условия труда» — 7, «Оплата» — 8. Тогда коэффициенты будут: «Интерес» — 40% (10/(10+7+8)=0,4), «Условия труда» — 28% (0,28), «Оплата» — 32% (0,32).

Коэффициент при факторе 1-го порядка покажет, какую долю в оценке займет этот фактор. Такой подход позволяет сильно влиять на результат в зависимости от предпочтений разных людей не меняя модели: кому-то уровень заработной платы в 2 раза (условно) важнее интереса в работе, а кому-то наоборот. В первом случае «Интерес» может получить 20%, «Оплата» — 40%, во втором соответственно наоборот.

Полученная сумма по каждому фактору 1-го порядка умножается на коэффициент этого фактора и делится на количество его факторов 3-го порядка. Затем полученные числа суммируются.

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

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

Самый лучший способ заполнить факторную модель — наличие «своего» человека в организации. Это особенно актуально, когда работу предлагают по рекомендации.

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

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

Модель должна быть сбалансирована по факторам 2-го порядка. Если фактор 2-го подяка имеет важное и широкое значение, то факторов 3-го порядка в нем должно быть много. Если значение слабое — мало. В остальных случаях количество факторов 3-го порядка должно быть примерно равным и относительно небольшим.

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

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

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

Материал разделен на три части: А — теория, Б — практика, В — создание мультизагрузочной флэшки.

А. Общая теория (популярно).

1. Железо.

Все физические устройства, которые используются нами повседневно для хранения информации (HDD, CD-ROM, флэшка, и даже флопик) — это блочные устройства ввода/вывода (block I/O device). Они могут подключаться к компьютеру через различные интерфейсы: IDE, SATA, eSATA, USB. Операционная система предоставляет единый прозрачный для пользователя и программиста прикладного ПО способ чтения/записи информации с/на эти носители.

С железом напрямую общаются драйвера. Драйвер — это программа, загруженная в операционную систему. Он является прослойкой между ОС и устройствами, представляя для ОС стандартный программный интерфейс блочных устройств I/O.

2. Данные на физическом диске.

Блочными эти устройства называются потому, что информация на них записывается и считывается блоками (секторами, кластерами) фиксированного размера. Размер блока кратен 512 байт. Блочный подход необходим для обеспечения высокой скорости работы дисковой подсистемы.

Сам диск форматируется (размечается) на низком уровне (на заводе). Диск состоит из цилиндров. Цилиндр — это окружность на пластине диска. Первые цилиндры расположена в центре пластины диска, последние — на внешнем краю. Каждый цилиндр делиться на секторы. В пределах секторов организуются блоки на диске. Помимо самих данных в блоках записывается информация для контроля ошибок. С этой информацией работает контроллер внутри жесткого диска и она не видна снаружи. Драйвер посылает команды контроллеру диска на уровне «считать 10 блоков 10 цилиндра 20 сектора».

Все полезные данные, записанные на носитель, организованы в разделы. В Windows каждый раздел обычно представлен в виде логического диска (C, D, E, …). На сменных носителях (флэшка, компакт-диск, флопик) как правило создан один единственный раздел, на внутренних жестких дисках — наоборот — обычно несколько разделов. Данные в разделе организованы в файловой системе.

Для каждого раздела может независимо устанавливаться свой размер блока — размер кластера. Он регулирует баланс скорость/экономичность. Блок — это минимальная адресуемая единица разметки на диске. Кластер объединяет несколько блоков — это минимальная адресуемая единица в разделе.

Таким образом устанавливается следующая логическая иерархия (от внизу вверх): блок, сектор, цилиндр — кластер — раздел — файл, каталог.

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

3. Разметка физического диска.

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

Так как на диске может быть несколько разделов, их нужно где-то перечислить с указанием пределов и свойств каждого раздела. Для этого служит таблица разделов, которая находится в начале физического диска (начало диска — это его первый блок в соответствии с адресацией). В классическом случае она входит в состав MBR (master boot record), которая целиком занимает первый блок. На всю таблицу разделов выделено 64 байта. Каждая запись таблицы состоит из адресов начала и конца раздела, типа раздела, количества секторов в разделе и флага «загруженности» раздела и занимает 16 байт. Таким образом максимальное количество разделов на диске ограничено четырьмя (16 × 4 = 64).

Так сложилось исторически, но со временем стало очевидно, что 4 раздела не всегда достаточно. Решение проблемы было найдено. Те разделы, которые размечены в заголовке диска (в MBR), назвали Primary (первичные). Их по прежнему должно быть до 4-х включительно. Дополнительно ввели понятие Extended (расширенных) разделов. Расширенный раздел включает один или более подраздел и не содержит файловой системы. Сам он является полноценным первичным разделом.

Так как подразделы расширенного раздела не перечислены в таблице разделов диска, их невозможно пометить как загрузочные. Загрузочный (bootable) раздел — это тот раздел, с которого начинает загружаться операционная система. Он отмечается флагом в своей записи таблицы разделов. Таким образом отметить можно только один из 4-х первичных разделов. Расширенный раздел загрузочным быть не может, так как на нем нет файловой системы.

Разметка расширенного раздела описана в в его начале. По аналогии с MBR существует EBR (Extended boot record), расположенная в первом секторе. В ней описывается разметка логических дисков данного расширенного раздела.

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

4. Файловая система.

Каждый раздел диска, предназначенный для хранения данных (т. е. все разделы, кроме расширенного) форматируется в соответствии с некоторой файловой системой. Форматирование — это процесс создания структуры файловой системы в некотором пространстве на диске — в разделе. Файловая система организует пользовательские данные в виде файлов, расположенные в некоторой иерархии каталогов (папок, директорий).

Структура каталогов и файлов в разделе в классическом случае описана в таблице файлов. Как правило таблица занимает некоторое место в начале раздела. После таблицы пишутся сами данные. Таким образом создается система, где структура описана отдельно, а данные (файлы) хранятся отдельно.

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

В процессе работы на диске могут возникать физические повреждения. Некоторые блоки могут становиться недоступными для чтения. Эти блоки называют «бэдами» (bad sector). Если в процессе чтения диска попадает бэд, происходит ошибка ввода/вывода (I/O error). В зависимости от того, в каком месте появился бэд-блок и сколько их появилось, может потеряеться либо часть содержимого файлов, либо в часть таблицы файлов.

При попытке записи в бэд-блок контроллер диска должен определить проблему и выделить для этого блока новое место на поверхности диска, а старое место из использования изъять (relocate bad block). Он делает это незаметно для ОС и драйверов, самостоятельно. Происходит это до тех пор, пока есть резерв места для переноса.

5. Работа с диском.

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

В ОС семейства UNIX все устройства хранения данных представлены в виде файлов в каталоге /dev:

• sda, sdb, sdc, … — физические диски (HDD, включая внешние, флэшки, IDE-сидиромы);

• fd0, fd1 — флопики.

Разделы на каждом из дисков доступны в виде sda1, sda2, sd3, …

Нумерация дисков происходит в том порядке, в котором их видит BIOS. Нумерация разделов — в порядке создания разделов на диске.

Чтобы сделать образ (образ — это побитовая копия информации, размещенной на диске или в разделе) диска целиком (например первого по BIOS — sda), нужно вычитать данные из /dev/sda в любой другой специально созданный для образа файл, используя программу последовательного копирования содержимого файла. Чтобы записать образ в файл, нужно при помощи той же программы вычитать данные из образа в /dev/sda. По аналогии можно создать/восстановить образ раздела (например, первого на первом диске — sda1), обращаясь к /dev/sda1 вместо /dev/sda.

6. Монтирование.

Чтобы «превратить» дисковое устройство в набор файлов и каталогов, к которым можно получить доступ, его необходимо примонтировать. В Windows как такового монтирования не существует. Там разделы просто подключаются к логическим дискам (C:, D:, E, …). Информация о том, какую букву присвоить какому диску, хранится в самой ОС.

В UNIX понятие монтирования является основоположным в работе с дисками и дает значительно больше гибкости, чем есть в Windows. Монтирование — это процесс привязки некоторого источника образа диска (это либо сам диск, либо файл с его образом) к некоторому каталогу в файловой системе UNIX. Файловая система в UNIX начинается из одной точки — от корневого каталога (/), и никаких логических дисков C, D, E не существует.

В начале загрузки ОС семейства UNIX в корневой каталог / монтируется раздел диска, помеченный как root (корневой). На разделе диска должны быть созданы служебные каталоги ОС, находящиеся в корне файловой системы. К ним могут монтироваться другие разделы, либо файлы могут записываться прямо в основной раздел (примонтрированный к /).

Ключевой момент заключается в том, что источник образа диска (блочное устройство, файл с образом или каталог уже примонтированной файловой системы) можно монтировать к любому каталогу на любом уровне вложенности файловой системы, которая начинается с /. Таким образом, разные логические разделы физического диска представляются каталогами в единой файловой системе в противоположность отдельным файловым системам разных логических дисков в Windows (там каждый диск рассматривается как автономная файловая система, имеющая свой корень).

Для монтирования необходимо указать файловую систему образа, опции монтирования и каталог, к которому будет привязка.

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

7. MBR — загрузочная область.

В начале физического диска обычно расположена MBR (master boot record). Это загрузочная область диска. При загрузке компьютера BIOS определяет какой диск является первичным (primary) и ищет на нем MBR. Если она найдена, то ей передается управление. Если нет, выводится ошибка о том, что загрузочный диск не найден.

В MBR, кроме таблицы разделов (описано выше), располагается код программы, которая загружается в память и выполняется. Именно эта программа должна определить загрузочный раздел на диске и передать ему управление. Передача управления происходит аналогично: первый блок (512 байт) загрузочного раздела помещается в оперативную память и выполняется. Он содержит программный код, который инициирует загрузку ОС.

За счет того, что управление от BIOS при загрузке компьютера передается программе, записанной на диске, есть возможность сделать выбор загрузочного раздела более гибким. Это и делают загрузчики GRUB и LILO, широко применяемые в мире UNIX. Последний загрузчик в настоящее время использовать на современных компьютерах смысла нет. С помощью GRUB можно предоставить пользователю выбор, какой раздел загружать и каким образом.

Код GRUB слишком большой, чтобы поместиться в MBR. Поэтому он устанавливается на отдельном разделе (обычно в том разделе, который монтируется в /boot) с файловой системой FAT, FFS или Ext2. В MBR записывается код, который загружает код GRUB с определенного раздела и передает ему управление.

GRUB самостоятельно или с помощью пользователя определяет с какого раздела должна происходить загрузка. В случае Winsows-раздела ему просто передается управление точно так же, как это было бы из обычной MBR. В случае Linux-а загрузчик выполняет более сложные действия. Он загружает в память ядро ОС и передает ему управление.

Сделать бэкап загрузочной области диска так же легко, как бэкап всего диска или отдельного раздела. Суть в том, что MBR занимает первые 512 байт диска /dev/sda. Следовательно, для бэкапа MBR необходимо вычитать первые 512 байт /dev/sda в файл, а для восстановления — наоборот — файл вычитать в /dev/sda.

Озадаченно смотрю на версии «свежего софта»…

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

Объясните — в чем смысл? Только в «проверенности» и стабильности этих версий?

Ответ:

Да. И это «только» весьма дорогого стоит. Более того, в рамках политики дебиана обновляться версии будут только на security fix’ы, то есть никаких новых фич до момента явного dist-upgrade’а. Сравните с убунтой, в которой каждые N дней пачка обновляемых пакетов.

Для десктопа это, может быть и нормально, но для сервера — неприемлимо. Я лично несколько раз сталкивался с дурацкими проблемами при обновлении версий (к счастью, только на декстопе). В списке лидеров — evolution (похерил архив почту), krusader (похерил половину настроек), deluge (криво подцепил старые настройки).

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

Таким образом, stable — это идеальное решение для сервера. А sid/ubuntu — вполне хорошо для _своего_ десктопа (решать проблемы похерившейся почты у себя неприятно, но решать их же у главбуха — куда грустнее).

Кстати, ровно той же политики придерживается и RHEL (CentOS) — у них в пятой версии до сих пор 2.6.18, хоть и с кучей бэкпортов.

© amarao, Хабрахабр.

Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное SSL-шифрование протокола HTTP, которое поддерживает любой современный браузер — HTTPS.

Причем, работает нормально HTTPS только в том случае, если для пользователя не произошло незаметной подмены сертификата (как это делает софт на подобии SecureTower). В случае, если сертификат подменяется незаметно или пользователя в открытую заставляют принять невалидный сертификат (т.к. иначе ничего не будет вообще) HTTPS работать перестает.

И вот, учитывая это, возникает вопрос: если полностью защитить трафик мы не можем, то можем ли мы защитить хотябы самое важное? Например, пароль. В принципе, можем, но тоже не на 100%. Пароль можно хэшировать до передачи на сервер JavaScript-ом. Тогда перехватчик получить хэш. Он сможет по нему авторизоваться, но сам пароль не увидит. Правда, его можно подобрать брутфорсом. С шифрованием самого пароля (вместо хэширования) картина примерно та же, только реализация гораздо сложнее.

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

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

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

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

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

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

А как делают другие?

Про Яндекс я уже рассказал. Добавлю, что пароль он передает в открытом виде и не пускает на главную страницу портала по HTTPS.

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

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

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

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

1. Домашний сервер на Debian 5.
2. Физический доступ к нему.
3. Доступ по SSH (не root).
4. USB-флешка с разделом NTFS.

Необходимо: быстро монтировать и размонтировать флешку для чтения/записи.

Вся проблема сводится к тому, что автомантирование флешек в Дебиане по дефолту делается штатными драйверами (read-only) и только с правами на монтирование. А мне необходимо было периодически скидывать инфу на флешку или с нее. Захотелось процесс оптимизировать.

Для достижения цели необходимо решить 2 задачи:

1. дать доступ к монтированию флешек (не всего, что попало, а именно USB NTFS флешек) рядовому пользователю без пароля,
2. избавить от необходимости полностью писать команду монтирования каждый раз.

Делается все очень просто. Я создал shell-скрипт /root/flash следующего содержания:

#!/bin/bash

case "$1" in
	1)
		mount -t ntfs-3g /dev/sdc /media/flash/
		;;
	0)
		umount /media/flash/
		;;
	*)
		echo $"Usage: $0 {1|0}"
		exit 1
esac

При передаче скрипту 1 происходит монтирование, при передаче 0 — размонтирование флешки (если точнее, то усройства /dev/sdc).

Ссылку на скрипт размещаем в /usr/bin для удобного доступа к нему:

# ln -s /root/flash /usr/bin/flash

Теперь надо разрешить выполнение этого скрипта без пароля от имени root с помощью sudoers. Выполните:

# sudoedit

И в файл добавьте следующие строки (замените feedbee на имя вашего пользователя):

Cmnd_Alias FLASH_CMD = /usr/bin/flash
feedbee ALL=(ALL) NOPASSWD: FLASH_CMD

Собственно, всё. Теперь из под вашего пользователя можно просто выполнить:

$ sudo flash 1

для монтирования флешки, и

$ sudo flash 0

для размонтирования.

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

Самый простой пример таких сайтов — это локализованные версии одного сайта на разных языках. У меня в практике — это тематические форумы для разных групп.

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

При запуске обработки пользовательского HTTP-запроса скриптам необходимо определить, какому именно домену предназначен запрос, и выбрать соответствующий конфиг. В PHP это довольно просто сделать: заглянуть в переменную $_SERVER['SERVER_NAME']. В других языках программирования под веб, думаю, примерно так же просто.

По имени серевера определяется нужный конфиг и оттуда берутся все необходимые настройки. Все просто.

Но когда дело доходит до вызова скриптов из cron-а (или другого планировщика), то переменная $_SERVER['SERVER_NAME'] будет пуста. Оно-то и понятно: никакого сервера нет, скрипт запускается напрямую через CLI. И узнать, для какого сайта вызывается скрипт, без явной передачи домена скрипту невозможно.

Самый простой способ указать домен — это прописать его аргументом командной строки. При вызове из cron-а после имени скрипта просто пишем домен, а в коде получаем его из переменной $argv глобальной области видимости.

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

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

Таким образом ищем более удобный способ передать «указатель» на сайт. И находим: это переменные окружения. Среду окружения интерпретатор PHP получает оттуда, откуда он был запущен. Если скрипт запущен веб-сервером, то переменные будут получены от сервера. Если запускается скрипт через CLI, то среда будет получена от shell-а, в котором производился запуск. Повторю: запуск скриптов из cron-а — это обыкновенный запуск исполнимого файла в режиме CLI.

Теперь к конкретике. Чтобы переменная среды окружения попала из веб-сервера в PHP-скрипт (или скрипт/программу, написанную на других языках), ее надо установить (прописать). Для Апача установить переменную можно в файле .htaccess, либо в конфигах сервера (httpd.conf или конфиги виртуальных хостов). В идеале предпочтительно последнее. Но достаточно и минимального уровня доступа к .htaccess. Добивим в соответствующий конфиг строку:

SetEnv SITE_NAME site1

Чтобы определить переменную среды при запуске в режиме CLI (php /filename), нужно ее объявить и экпортировать:

export SITE_NAME=site1;

При запуске скрипта вручную следующей командой можно запускать сам PHP. Если запуск производится cron-ом, то стоит создать скрипт, на который ссылаться из crontab:

#!/bin/bash
export SITE_NAME=site1;
php /path

Для других сайтов вместо site1 подставляются другие имена.

Остается прочитать переменную в скрипте:

echo getenv('SITE_NAME');

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

* Стоит отметить, что в случае разных «установок»¹ одного и того же сайта (development, testing, production) принято это значение передавать сайту в виде тоже же переменной окружения. Как правило, конфиг в этом случае содержит очень много информации, одинаковой для всех «установок», а отличаться, например, могут только параметры доступа к БД. Тогда имеет смысл все установки считать за один сайт (хоть домены и разные), а отличающиеся параметры вынести в отдельный конфиг, зависимый от «установки».

¹ — Я намеряно в последнем абзаце заменил термин «окружение приложения» (application environment: тестовое, рабочее) на «установку», чтобы не было путаницы с тем окружением, где устанавливаюся переменные.

Виджет очень пока простой, содержит самый базовый функционал. Размер виджета минимальный — 1×1. При нажатии на его видимую обалсть выполняется USSD-запрос на получение баланса лицевого счета: *100#. Такой запрос используется в Беларуси всеми тремя GSM операторами.

База логотипов в программу встроена. На данный момент поддерживается только 4 оператора: МТС (Беларусь), Velcom, Life:) и Dialog. Распознавание оператора произыодится по коду сети. Название оператора в любом случае отображается так, как его отдает сеть.

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

В данный момент доработана первая публичная версия. Статус — бета.

Сайт программы.

Скачать:

Так выходит, что человеку в жизни на длинных отрезках (расстояния, времени) удобно ориентироваться по их частям. На дороге есть километровые знаки, в лифте — дисплей текущего этажа, в году — дни, а в жизни — годы. Именно на прожитые годы делится отрезок всей жизни человека.

Наверное именно по этому в конце года принято подводить его итоги, начинать планировать следующий. Это касается и бизнеса, и личных вопросов. Поэтому сейчас, за 2 часа и 50 минут до начала нового 2011 года, я решил кратко подвести итоги «своего» 2010-го.

Этот год стал переломным в моей жизни и насыщеным самыми важными событиями моей послевоенной истории (взрослой жизни).

1. В феврале 2010 я женился.
2. В июне 2010 я закончил заочное обучение в университете и получил диплом программиста.
3. В июле 2010 у меня родилась дочь.
4. В октябле 2010 на работе наконец-то был запущен проект, на которым я работал последние пару лет (с перерывами).
5. В ноябре 2010 я начал читать книги.
6. Тогда же я начал ценить и планировать свое время.
7. В декабре 2010 мой блог стал приносить прибыль.
8. Тогда же скорость моего анлима (интернет без учета трафика) достигла 2 МБит/с.

Кроме этого, в 2010-м я значительно повысил свой профессиональный уровень и научился получать большее удовольствие от повседневности.

Этот год для меня был длинным, запоминающимся, интересным и счастливым.

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