Итак, после моей предыдущей статьи я понял что тема про программирование драйверов Windows интересна хабровчанам, поэтому продолжу. В этой статье я решил разобрать простую программу-драйвер, которая делает только то, что пишет отладочное сообщение «Hello world!» при старте драйвера и «Goodbye!» при завершении, а также опишу те средства разработки, которые нам понадобятся для того, чтобы собрать и запустить драйвер.

Сейчас будем ставить замечательный фреймворк GWT.Эта статья не претендует на оригинальность, подобных статей можно найти множество, но все же я решил написать пошаговый ман по установке, раз уж мой топик первый.Можно писать свои приложения в своем любимом редакторе, но я решил, что уж раз есть возможность прикрутить gwt к такой замечательной среде разработки как Eclipse, то писать и использовать будем ее.

Итак что нам необходимо для начала работы:

Надеюсь те, кто были на моем портале видели первую версию проекционных часов. Я изготовил вторые. Данная статья частью дублирует тот материал. А частью раскрывает грабли на которые я наступил. Никаких микроконтроллеров внутри, доступно для повторения всем!)

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

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

Чем ближе Ваш сайт приближается к концепции Web2.0 тем больше JavaScript-кода появляется на Ваших страницах. Очевидно, что разработчику все больше времени приходится тратить на интеграцию своего серверного кода на php/java/python… с клиентской частью на JavaScript.

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

В данной статье я расскажу о своём опыте реализации всплывающего модального окна с некой формой и submit-кнопкой на ASP.NET + jQuery и с теми ошибками, с которыми я столкнулся.

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

Каждый курс содержит видеозаписи лекций, полные тексты и тезисы, а также практические задания и экзаменационные билеты. Материалы практически полностью совпадают с той программой, по которой учатся студенты-очники в Стэнфорде. Чтобы скачать материалы, не требуется никакой регистрации или специального запроса. Они просто выложены в открытый доступ в ZIP-архивах примерно по 300 МБ, а видеоролики ещё продублированы на YouTube.

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

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

1. Маркетинговая

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

1. Прикидываю примерно, какие цели могут быть у клиента (именно его личные специфические цели по использованию сайта для его компании)
2. Составляю mindmap с примерной структурой, функциональностью и задачами сайта
3. Отрисовываю бумажный прототип, чтоб клиент могу «пощупать» как будет работать его сайт, если он согласится

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

2. Предохраняющая

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

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

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

Кроме того, если клиент вас решит кинуть на первых этапах, то вы не потратите ничего, кроме 10 листов бумаги и времени.
Совсем недавно именно так у меня и случилось, потому и расстраиваться особо не пришлось.

Что думаете на этот счет?

С рассветом WEB 2.0 получили развитие и javascript фрэймворки, позволяющие вебмастеру делать динамические элементы сайта гораздо быстрее и проще. Одним из таких фреймворков является jQuery, получивший огромную популярность за свою простоту и невероятно малый вес. Итак, представляю вашему вниманию 10 наиболее полезных скриптов jQuery для улучшения интерфейса вашего сайта.

Разгоняем счетчики: от мифов к реальности

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

На самом деле, все не так плохо. Скорее, все очень хорошо, но мало кто об этом знает :)

Заглянем внутрь

Что из себя представляет код JS-счетчика? Обычно (в 99% случаев) он «вытаскивает» из клиентского окружения набор параметров (URL текущей страницы, URL страницы, с который перешли на текущую, браузер, ОС и т.д.), которые передаются на сервер статистики. Все навороты счетчиков связаны с обеспечением максимальной точности передаваемой информации (кроссбраузерность, фактически). Наиболее мощные (Omniture, Google Analytics) используют еще и собственные переменные и события, чтобы усилить маркетинговую составляющую.

Но сейчас речь не об этом. Как собранные на клиенте данные попадают на сервер статистики? Все очень просто: в документе создается уникальный элемент, в URL которого «зашиваются» все необходимые значения (обычно в качестве GET-параметров). URL этот ведет, как можно догадаться, на сервер статистики, где данные кладутся в базу и каким-то образом показываются в администраторском интерфейсе.

Читать дальше на webo.in→

Наверняка не ошибусь, если напишу, что каждый программист хочет работать максимально эффективно, а каждый работодатель хочет, чтобы все его работники были максимально эффективны. Однако на самом деле часто бывает так, что даже самый мотивированный и профессиональный программист не может работать эффективно, а работает только на 10-20% своей силы. И постепенное его мотивация угасает, а 10-20% превращаются в 1-5%.
Из-за чего это может происходить?
А происходит это из-за многочисленных преград, которые мешают работать эффективно.
Часть из этих преград невозможно убрать, не сменив работу, а с большинством можно бороться и побеждать их и именно об этом пойдет речь в этой статье.
Ниже — мой личный топ-список таких преград с комментариями для программистов и примерами из моей жизни.
Думаю, примерно такой же список актуален и для других IT-профессий.

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

В моей работе нужно анализировать качество проектов и иметь полное понимание о том, как мы учимся не наступать на одни и теже грабли. Для этой цели есть много инструментария, но я хочу поделиться опытом с теми, кто как и наша студия использует в роли багтрекинга Mantis 1.1.1 (написан на PHP, БД- MySQL)

Этот топик — приглашение к обсуждению. В конце обещаю очень полезную вещь.

В последнее время, все больше появляется бесплатного и открытого. Все понятно, когда Google делает великолепный инструмент на котором можно было бы много заработать (SketchUp) — бесплатным — все понимают, что компания и так зарабатывает много денег и ей важнее заполучить больше пользователей. Хотя и есть платная версия. Однако все больше и больше из нас придумывают новые идеи, такие как YubNub (сервис не мой), и подобные, которые облегчат жизнь пользователям. Сделать — день-два, отладить неделя-десять, донести до ума пользователей — год.

Однако встает вопрос — тратить время на развитие сервиса — это терять деньги. Элементарно — сервер, люди, личное время — все деньги отнимает. Раньше эту проблему могла бы решить реклама…

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

Я уже писал, что программирование – это игра, как и любая игра, она состоит из стадий или уровней. Что бы стать настоящим профессионалом, важно уметь проходить эти стадии. Порой это трудно, порой даже очень трудно, но согласитесь, от этого только интересней!
Сейчас я постараюсь выделить основные стадии и опасности, подстерегающие программиста на этом сложном, долгом и очень захватывающем пути. Попробую рассказать, как именно эти стадии проходить, что нужно делать, что бы не свернуть, и не оказаться одним из тех, кого я называю «НЕДОпрограммистами».

Навеяно прошлым топиком.

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

Выкладываю фреймворк, написанный для себя.
Причина создания: надоело каждый раз при верстке нового сайта заниматься одним и тем же — переделывать мой любимый Tripoli (исправляя его баги, добавлять свойства разметки); добавлять JS-фреймворк jQuery, создавать типичную HTML-структуру. Решил объединить часто используемые мной элементы в единое универсальное целое.
Делал для себя, то есть — аккуратно и хорошо.

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

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

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

Хорошая мотивация сотрудников — это по сути важнейшее условие успешности любой компании. Не только в сфере IT, но в IT — особенно. Ведь известно, что мотивированный сотрудник может сделать работу в разы быстрее и, главное, качественнее.
Надо сказать, что всевозможных методов мотивации сотрудников известно очень много. Казалось бы, что нет ничего проще — читай, внедряй и получай эффективных и мотивированных сотрудников.
Однако последнее время всё чаще встречаются статьи, где авторы пишут, что финансовая мотивация — это зло. Например одна из лучших статей Joel Spolsky О вреде премирования. А некоторые и вообще пишут, что метод кнута и пряника уже не работает.
Мало того, в России до сих пор многие руководители не понимают важности мотивации и лояльности сотрудников и уделяют этому вопросу недостаточно внимания, считая, что сотрудник должен быть доволен уже самим фактом работы в компании.
При этом есть множество книг и статей, где одни руководители и менеджеры рассказывают другим про то, какие методы мотивации наиболее эффективны. Но знают ли они про это на самом деле? Не правильнее ли про лучшие методы мотивации узнавать у тех, кого пытаются ими мотивировать?
Я не собираюсь тут писать еще одну статью про мотивацию — их и так много, хотя мог бы, так как побывал и программистом и менеджером и пробовал разные методы мотивации на себе и на других. Но сейчас я хотел бы просто задать несколько вопросов.

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

Задумайтесь и напишите в комментариях, какие из методов мотивации наиболее сильно воздействуют именно на вас?
Так ли бесполезны и вредны премии в вашем конкретном случае? Премии за что вы считаете наиболее и наименее мотивирующими?