Главный блог dev.by

Добрый день, уважаемые коллеги!

Как известно, для того, чтобы стать первоклассным специалистом, недостаточно закончить ВУЗ. Это как никогда верно в IT сфере — нам приходится получать новые знания постоянно! Кроме того, пора кризиса заставила активно совершенствовать знания и навыки, для того, чтобы оставаться конкурентноспособными на рынке труда.

Но как обстояли дела в спокойное время? Стремились ли Вы узнавать новое? Стремились ли совершенствовать свое мастерство? Как Вы это делали?

После полугодового застоя рынок рабочей силы в IT начал оживать. Пословица “Была бы шея, а хомут найдется” снова становится актуальной. Многие начали задумываться о смене работы, тем более что в кризис разные компании по-разному обошлись со своими сотрудниками. Всех затронули снижение заработных плат и сокращения соц. пакетов. Одни компании пострадали в большей степени, другие в меньшей. Сегодня снова появляется возможность выбора, выбора лучшего места работы. Чего же мы хотим от потенциального работодателя? Все рассуждения далее по тексту носят чисто субъективное мнение автора. Однако автор надеется, что его разделит большинство читателей.

Мои хочу:

Если вы руководите ИТ-шниками или сами являетесь ИТ-специалистом, вы с вероятностью 99% играете сами или вас заставляют играть в самые изощренные психологические игры. Цели игр разные, но выигрывает в них зачастую только тот, кто начинает играть и знает во что он играет. Второй игрок практически всегда проигрывает, разве что он знает эти Игры, умеет их вовремя распознать и выходить из них.

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

За четыре вечера, с 3 по 6 августа, спасаясь от дневной жары поздней ночью, мы рассмотрим типичные и редкие психологические игры, которые встречаются в мире ИТ. В эти игры играют менеджеры проектов, программисты и тестировщики, а иногда даже руководители и заказчики.

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

Данные советы взяты из книги Стива МакКоннела, опубликованной в рамках серии Microsoft Best Practices. Эта книга общепризнанна в качестве ценного источника знаний и рекомендована всем тем, кому приходится заниматься оценкой проекта – менеджерам проектов разработчикам, тимлидам и т.д. Разумеется, данные советы, перечисленные в этом посте, не являются исчерпывающими, и рассматриваются в первую очередь в их первоначальном контексте. Но, тем не менее.

Оговорюсь сразу, что я не DBA. И я даже не напишу триггер без мануала. Однако мне посчастливилось приобрести неплохой опыт в разработке и оптимизации баз данных. Этим опытом я и хочу поделиться. Я хочу привести простой список, который, я надеюсь, поможет вам выявить узкие места в работе с СУБД на ваших проектах. Все это мои личные наработки, поэтому на какую либо полноту, упорядоченность, уникальность и безоговорочность они претендовать не могут. Итак, начнем.

При первом знакомстве с jQuery, после долгих отношений с mootools, впечатление было неоднозначное. Больше всего раздражали классы. Точнее, отсутствие в jQuery классов, наследования, и всего такого. - Как? - спрашиваю я - Совсем нет?. - Совсем нет - отвечали коллеги. А доки по jquery вообще деликатно промолчали на эту тему, упорно упоминая слово class только рядом с CSS.

Но, как известно, если долго мучаться, что нибудь получится.