typedef

С новым годом, кстати.

Настройка Emacs — это определенно то дело, которым стоит заниматься линуксоидам в Windows (после сборки чего-нибудь из исходников, разумеется). Замечательно успокаивает нервы и нормализует давление.

Что бы там ни говорили, а Emacs невыгодно отличается от своих аналогов долгим временем начальной загрузки, особенно если в процессе оной грузится пара десятков дополнительных модулей. Но если для открытия файлов, скажем, *.el, назначить файл runemacs.exe редактором по умолчанию, то попытка открыть несколько файлов приведет к открытию равного количества экземпляров Emacs, со всеми вытекающими задержками и издержками. Мы же хотим, чтобы было как в Notepad++: редактор запускается один раз, и дальше все файлы открываются в нем.

Как сказал один емаксер, «учитесь любить Emacs Server». Учимся:

1. типы файлов, которые хотим открывать Emacs’ом, ассоциируем с %EMACSDIR%\bin\emacsclientw.exe;
2. создаем переменную окружения ALTERNATE_EDITOR="%EMACSDIR%\bin\runemacs.exe";
3. в начало файла .emacs (или init.el, у кого что) вставляем:
   # run emacs server
(server-start)

Теперь когда мы открываем файл, emacsclientw пытается найти запущенный Emacs-сервер. Если не находит, обращается к альтернативному редактору (runemacs), который открывает файл и запускает сервер. Если же сервер уже запущен, то файл просто открывается в новом буфере.

(2 голосов, средний: 5.00 из 5)

 Loading ...

Почти во всех мобильниках есть камеры. Во многих есть встроенный GPS. Почему бы не кодировать географические координаты штрих-кодом?

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

Или, например, можно размещать такие координаты в рекламе или на визитках. Включаем воображение и видим светлое будущее. Осталось только:

1. договориться о формате кодирования;
2. встроить простенькую распознавалку в программы GPS-навигации.

(Еще не оценили)

 Loading ...

Установил я как-то Windows 7, и зело он мне приглянулся. Пожалуй, из всего, что я видел, здесь самый удобный интерфейс и самая высокая работоспособность «из коробки» (правда, я не пробовал еще MacOS и всякие маргинальные клавиатурно-ориентированные иксовые оболочки вроде xmonad). И GUI визуально шустрее, чем на моей Федоре. Так что на данный момент «господин назначил Windows любимой осью», и пингвинов загружает только по необходимости или нестерпимому зову сердца.

Чем занимается линуксоид, обретя свежую винду? Конечно же, собирает что-нибудь из исходников! Вот я и решил собрать себе последнюю Qt, да не просто собрать (этак можно MinGW прикрутить и спать спокойно), а так, чтобы почти вся разработка происходила в Visual Studio, и компилятор использовался местный, а не портированный. И чтоб отладка тоже из IDE.

Ну что ж, дело нехитрое:

1. качаем Qt и устанавливаем ее, скажем, в C:\qt\2009.05;
2. на всякий случай копируем в C:\qt\4.6;
3. устанавливаем переменные окружения:
   QTDIR=C:\Qt\4.6\qt;
   QMAKESPEC=win32-msvc2008;
   добавляем C:\Qt\4.6\qt\bin в Path;
4. дистрибутив версии 4.6 содержит забытые авторами временные файлы, которые приводят к ошибкам при сборке (настоящий opensource не собирается с первого раза, но зато всегда можно найти ответ на официальном сайте), поэтому нужно удалить файлы:
   C:\Qt\4.6\qt\src\script\tmp\moc\debug_shared\mocinclude.tmp
   C:\Qt\4.6\qt\src\script\tmp\moc\release_shared\mocinclude.tmp
   C:\Qt\4.6\qt\src\3rdparty\webkit\WebCore\tmp\moc\debug_shared\mocinclude.tmp
   C:\Qt\4.6\qt\src\3rdparty\webkit\WebCore\tmp\moc\release_shared\mocinclude.tmp
   будем надеяться, что в следующих релизах эта ошибка будет исправлена;
5. запускаем Visual Studio, и из нее консоль (Tools → Visual Studio 2008 Command Prompt);
6. переходим в C:\Qt\4.6\qt;
7. запускаем configure, отвечаем на его вопросы; начнется подготовка к сборке, которая продлится минут 5-10;
8. запускаем nmake, начнется сборка, которая продлится несколько часов (есть смысл оставить на ночь); в ходе сборки будет куча предупреждений, но не стоит принимать это близко к сердцу, главное чтобы процесс сборки не завершился сообщением об ошибке;
9. закрываем Visual Studio, качаем и устанавливаем add-in;
10. запускаем Visual Studio, идем в Qt → Qt Options и указываем там версию вместе с путем к установленному Qt;
11. C:\Qt\2009.5 можно стирать;
12. все.

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

Если ставить LGPL-версию Qt, то Qt Designer не будет интегрирован в VS, а запустится отдельно при открытии UI-файла. Это, конечно, неудобство, но не критичное.

(2 голосов, средний: 5.00 из 5)

 Loading ...

Гугл меня сегодня чуть не убил, натурально. У меня на главной странице виджет с погодой. Смотрю утром: +4º. Ну, думаю, опять синоптики облажались со своими морозами. Оделся соответственно погоде, по-осеннему. Приезжаю на работу — а Гугл показывает уже -18º. Тут-то я и понял, почему мне по дороге казалось, что как-то несколько прохладно для четырех градусов…

К сожалению, скриншот сделать не смог.

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

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

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

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

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

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

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

(2 голосов, средний: 5.00 из 5)

 Loading ...

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

Истоки такого альтруизма программистов можно обнаружить в культуре хакеров, начавшейся аж в 60-х годах. Об этом можно почитать в замечательной книге Стивена Леви «Хакеры». В то время свободное ПО было практически единственным вариантом: рынка софта как такового не было — был рынок железа. Общей аппаратной архитектуры не было, цены были фантастически высокими, и компьютеры являлись штучным товаром, к которому софт поставлялся в виде бесплатного дополнения.

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

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

Но жизнь-то — штука изменчивая, и вот, подвинув бородатых хакеров, за терминалы уселись банковские служащие и бухгалтеры. Потом все нарастающая стандартизация аппаратуры, платформенная независимость языков программирования, и вдруг — хоп! Программисты остались в меньшинстве, железо стало дешевым, а одну и ту же программу можно, хвала Юниксам, если не запустить, то уж собрать почти на любой платформе. Собственно, исчезли основные предпосылки существования опенсорса, имевшие место в 60-е и 70-е.

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

1. Интерес. Людям просто нравится творить. Но так как большинство программистов — не бизнесмены, и не способны продать свои творения, они их просто раздают. Впрочем, есть и идейные, которые раздают из принципиальных соображений.
2. Известность. Open source очень демократичен. Напиши хорошую программу, которой будут пользоваться миллионы, — и интерес к тебе со стороны работодателей сразу повысится. Собственные разработки с открытыми исходниками служат отличной заменой традиционным резюме: просмотрев исходники программы и историю ее разработки, можно гораздо больше узнать о разработчике, чем в ходе получасового собеседования.
3. Работодатель за это платит.

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

1. Код с открытыми исходниками не является самодостаточной программой, а представляет собой некую библиотеку или фреймворк, являющиеся побочным продуктом при разработке чего-то большего. Исходники открываются, как правило, из рекламных соображений. Прибыль косвенная.
2. Компания активно использует свой же продукт с открытыми исходниками в своих разработках. Очевидно, что основная прибыль получается другими путями, а открытие исходников — просто жест доброй воли или, опять-таки, реклама. Прибыль снова косвенная.
3. Мифическая «техподдержка», о которой будет твердить не слишком подкованный апологет open source, объясняя, откуда у опенсорсников деньги берутся. Этот путь получения дохода имеет смысл разве что для крупных компаний вроде Rad Hat или Microsoft, которые могут поставлять настолько большие и сложные продукты, что для них может потребоваться обучение специалистов и поддержка (платные, разумеется).
4. Open source, вообще говоря, ничуть не противоречит коммерческому софту. Поэтому можно путем хитрого лицензирования требовать с клиентов денег, если продукт с открытыми исходниками используется в коммерческих разработках (вспомним Qt как хрестоматийный пример).
5. Научные гранты.
6. Всякие маргинальные способы вроде пожертвований или встраивания рекламы в пользовательский интерфейс (фуу).

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

Программистов, которые могут себе позволить и хотят заниматься разработкой открытого софта, подавляющее меньшинство. Качественный открытый софт убивает конкуренцию (и, в некотором смысле, прогресс) среди закрытого коммерческого софта. То есть, если разработана некоторая открытая программа, то вероятность появления успешной аналогичной (или даже чуть более функциональной) закрытой коммерческой программы исчезающе мала (пример — браузеры). Да и открытой, в общем-то, тоже. Выходит, что open source замедляет прогресс!

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

1. Я написал научную статью и выложил ее в открытый доступ. Это ускоряет развитие науки, так как другие ученые могут опираться на мои результаты.
2. Я написал библиотеку нечеткой логики и открыл ее исходники. Это ускоряет прогресс программирования, так как остальные разработчики могут сэкономить свое время, если им понадобятся такие функции. Если им нужно внести какие-то изменения, они берут и вносят. Здесь важно, чтобы лицензия открытого кода позволяла любое его использование, в том числе коммерческое.
3. Я написал редактор UML-диаграмм и раздаю его бесплатно. Это помогает другим разработчикам в их работе. Конечно, это убивает конкуренцию среди платных редакторов UML, но в целом служит прогрессу программирования.
4. У меня бессонница, поэтому я год ночами писал программу управления личными финансами, а так как мне лень заниматься продажами, то я раздаю эту программу бесплатно. Если программа удобная, то платные уже покупать никто не будет, даже если они немножко лучше. Конкуренцию теперь может составить только более функциональная бесплатная программа.

Итак, моя позиция по поводу всего вышеобозначенного:

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

(1 голосов, средний: 5.00 из 5)

 Loading ...