В продолжение моего wordpress-творчества представляю новую тему — Constructor.

все нижесказанное ↓ имхо

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

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

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

Как обещал в одном из комментов — публикую свой опыт перехода на линуксы. Рассказ будет несколько сумбурным. Потому что я не писатель и, собственно, таким и был переход.
Все началось с планирования бюджета на 2009-й год. Составив бюджет я понес его начальству. Увидев сумму в 400 т.р. статьи «Расходы на ПО» начальство задумалось.
— С линуксами знаком?
— Ну дома стоит…
— Контору на них перевести сможешь?
— Терминал-сервер оставить надо на винде (1с и еще ряд задач), а вот остальные машины, в принципе, реально.
Так и начался переход. Дистрибутив выбрали убунту. Во-первых, потому что дружелюбный, а во-вторых, потому что с остальными дистрами я толком не общался.

Пост написан от некоторого отчаяния. Дело в том, что общение по рабочим вопросам с людьми (с клиентами, партнёрами, исполнителями) стало потреблять слишком много моих ресурсов (времени, внимания). Более всего утомляют инструменты общения, выбранные моими собеседниками.

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

Телефон, Skype и прочие VoIP

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

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

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

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

Телефонные звонки не оставляют логов. Максимум, что обычно можно узнать о прошлых звонках: кто, кому, когда звонил. И совсем ничего относящегося к содержанию разговора. А содержание важно хотя бы даже для последующего разбора полётов.

Недавно я для себя открыл простую модель, которая обьясняет, какие инструменты нужны менеджеру и команде для ведения и управления проектами.

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

Введение

Доброго вам времени суток, уважаемые хабрачитатели. Многие из вас знают, как приходится работать администраторам в не ИТ компаниях или в компаниях где начальство, даже близко не стояло со сферой ИТ. Насколько тяжело доказать свою правоту, объяснить смысл внедрения определенной технологии. Также не все понимают, чем же именно занимается системный администратор. Многие не замечают, что они постоянно дергают админа (там почта не работает, тут принтер бумагу зажевал, а где-то вообще интернет не «открывается»). Наверняка многие из администраторов работают по системе: получили письменную заявку – выполнили задание – все счастливы.

Однако, никто не пишет заявку для того, чтобы ему вытащили застрявшую бумагу в принтере. А большинство таких просьб и заполняют весь рабочий день, и на реальную работу остаётся не так уж и много времени, и когда начальник требует отчета, сказать как бы нечего, ибо документа доказывающего вашу работу нет. Частичная занятость (по документам) есть, а что же вы делали все остальное время? Ну конечно, вы наверное, целый день игрались за компьютером.

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

Во-первых, это приложение однопоточное. Всё делается одним процессом, работа с сокетами — неблокирующими epoll/select, никаких ожидающих ввода/вывода потоков (threads). С развитием HTTP, сначала появлением Keep-Alive, затем AJAX и набирающим популярность COMET, количество постоянных соединений с веб-сервером растёт, на нагруженных проектах измеряется тысячами и даже десятками тысяч, и если для каждого создавать свой поток (thread) со своим стеком и постоянно переключаться между ними — ресурсов сервера очень быстро не хватит.

Второй ключевой момент — что один SELECT… WHERE pk in (k1, k2, ..., kN) выполняется быстрее, чем несколько SELECT… WHERE pk=… Выполняя работу с базой данных большими пачками можно уменьшить не только число запросов в секунду, но и общую нагрузку.

(ч1. Подделка межсайтовых запросов; ч3. Работа с пользовательским вводом)

Друпал предоставляет свои собственные средства для доступа к базе данных.

Во-первых, это позволяет не зависеть от используемого типа СУБД. К слову, на сегодняшний момент, полностью функционирует прослойка для MySQL и PostgreeSQL. В седьмом Друпале этот список будет расширен Ораклом и SQLite.

Во-вторых же, прослойка БД позволяет защититься от SQL инъекций.

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

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

Под катом много букв! Чтоб не потеряться в их обилии все пункты выделены заголовками.

Work on Stuff that Matters: First Principles

опубликовано 11 января 2009 года

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

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

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

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

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

1. Создать новую директорию в sites/all/modules, например my_module
2. Создать файл my_module.info в директории my_module, содержащий это:
3. Создать файл my_module.module. Полностью скопировать отсюда первый пример и вставить в my_module.module.
4. Включить модуль «My module» на странице модулей (admin/build/modules).
5. Перейти на страницу my_module/form для запуска кода.
6. Далее вам предстоит провести для каждого примера, полную замену содержимого my_module.module на код последующего примера. Не забывайте после этого переходить на страницу my_module/form для того, чтобы увидеть результаты своей работы.

А дальше огромная куча кода »

Вторая версия статьи, расширенная и дополненая.

Большая часть готовилась для моего выступления на «РИТ: Клиентские технологии», куда я, к сожалению, не доехал.

 



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

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

Начинаю вести серию статей Это статья про вёрстку html css js, начинаю с самого простого, потом планирую описать более сложные вещи и всякие тонкости и этим видимо так и закончил

Существует много пособий по настройке программ (Операционок, сервисов, сайтов и тд), но редко можно встретить мануал по организационным вопросам связанным с системным администрированием. Сразу скажу, опыт работы у меня достаточный. Рассматриваться предмет будет на моем личном примере работы, сразу скажу что любые аргументированные дополнения, и исправления приветствуются. Также поясню для господ минусующих: «Не нравится? Сделай лучше!», и обязательно пришли ссылку, почитаю с большим удовольствием.

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

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

Что да как

Я решил поддержать начинание MaxElc и DarwinTenk, и начать потихоньку рассказывать про Java. Текст буду подавать «чашками» потому, что один из символов Java — чашка кофе. Большую часть я буду писать сам, изредка поглядывая в википедию и на официальный сайт языка — java.sun.com (раздел /docs).
Далее в тексте стоит разделять понятия «Java как язык» и «Java как платформа».

Брюс Эккель, автор бэст-сэллеров «Thinkin in Java» и «Thinking in C++», выпустил новую книгу «Python 3 Patterns & Idioms».
Книга доступна в форматах html и Windows Help.
Распространяется по лицензии Creative Commons Attribution-Share Alike 3.0.
Линк

Мотивирование на «работу на Результат» — общепринятая практика деловой манипуляции. Это один из наиболее эффективных способов, например, для вышестоящего руководителя сохранить управляемость подчинёнными ему подразделениями. Говоря точнее, это удобный способ «тыкать пальцем» в дыры в бизнес-процессе, которые нижестоящий руководитель должен был закрывать. Нет результата — нет премии. Нет результата — значит человек зря занимает своё место. Если ваша цель, ваша забота или даже мечта вашей жизни — это «Результат», то это значит, что вы концентрируетесь на том, чем не можете управлять, и упускаете то, чем управлять можете.