При знакомстве с фреймворком, я первым делом смотрю не на его возможности, а на готовые решение, которые он предоставляет. В частности возможность удобно собирать JS/CSS файлы по частям и «отдавать» согласно рекомендациям по клиентской оптимизации (YSlow/Google PageSpeed). Ни в одном из просмотренных мной, нужной мне реализации я не увидел, даже в Django (которым, собственно, и был вдохновлен), поэтому решил сделать свое решение в виде готового к применению модуля для Kohana v.3.

Итак, опишем основные потребности/хотелки, которые ставились перед разработкой модуля:
1) Сборка inline CSS/JS по кусочкам
2) Возможность отдавать п.1 путем вставки в код страницы либо сгенерировав и записав на диск файл, с уникальным именем.
3) Возможность сборки внешних файлов CSS/JS в один билд
4) Возможность указывать условие, при котором подключается тот или иной билд из пункта 3, а также любой другой внешний файл (

<!--[if IE 7]>

).
5) Возможность вынести статику на другой домен, главное чтобы он был на этом же физическом сервере.
6) Использование CDN
7) Минимизация CSS/JS.
8) Самое важное: СПОСОБ, позволяющий включать статику (а эо обычно не только CSS/JS, но и, например. картинки) в распространяемые модули. Так как текущий способ, когда в modules/ переносится и подключается сам функционал модуля, а статика либо копируется в произвольное место DOCUMENT_ROOT, либо обязательное условие – чтобы modules находилась в DOCUMENT_ROOT.
9) Возможность легко менять URL со статикой, чтобы он никак не конфликтовал с роутингом, например будет не хорошо, если вы захотите иметь раздел про CSS по урл ”/css/” когда до этого вы сделали это реально существующей директорией с файлами стилей.

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

В данной статье рассматривается реализация multiseat на базе Ubuntu 10.04 LTS с аппаратным ускорением. Пример, рассмотренный в этой статье, уже введен в эксплуатацию и работает около полугода в обычном Минском офисе. Описываются проблемы реализации и внедрения готовой системы в работу с точки зрения обычного студента-электроприводчика, который подрабатывает на полставки системным администратором.

Вступление

Вот время работы системным администратором в небольшом офисе при обновлении парка компьютеров появилась небольшая проблема. Современные компьютеры дают уровень производительности, много превосходящий необходимый для офисных компьютеров. Причем реалии рынка таковы, что различия в производительности мало сказываются на цене. И вроде бы дешевые компьютеры на базе Atom по ценовому признаку практически не отличаются от более производительных компьютеров на базе обычных процессоров Amd и Intel (материнская плата с процессором Atom стоит около 100-150 у.е. на май 2010 года, Минск, и та же цена на октябрь 2010 в том же Минске).

Та же ситуация и с жесткими дисками: для офисной работы нет необходимости в объеме диска более 40-80 Гб. Но на рынке такие жесткие диски уже практически не представлены. На момент написания статьи в продаже были жесткие диски емкостью 160 Гб (38$), 250 Гб (39$), 320 Гб (40$), 500 Гб (41$), дальше различия по ценам заметны сильнее. Цена за гигабайт жестких дисков малого объема довольно высока. Та же ситуация и со всеми остальными комплектующими.

Возникает закономерный вопрос, как рационально все это использовать? Давайте подойдем логически — чтобы удешевить систему можно либо купить комплектующие похуже (не сильно удешевляет), либо отказаться от некоторых комплектующих. По сути, в рабочем месте обязательными являются устройства ввода (клавиатура, мышь, планшет и т.д.) и устройства отображения информации (монитор, проектор и т.д.). Остальная часть системы пользователей особо не касается, и от нее можно избавляться. Безусловно, от всего избавиться не получится. Давайте заглянем под крышку системного блока. Тут мы обязательно видим материнскую плату, видеокарту (может быть уже на материнской плате), процессор (тоже может быть на материнской плате) и память. А вот остальные комплектующие уже не так важны. Оптический привод мало востребован, и поэтому его, скорее всего, не будет.
С жестким диском тоже интересная ситуация. Его может и не быть, тогда у нас будет так называемая бездисковая станция. Тут вся информация загружается по сети с сервера (реализация PXE+NFS и немного бубна). Но хочется чего-то большего.
Тогда и возникла идея подключить к одному компьютеру две клавиатуры, две мыши и два монитора и заставить их работать независимо. В зарубежных источниках такие системы называются multiseat.
Но можно на этом и не ограничиваться, а делать бездисковую multiseat-станцию. Этот вариант отлично подойдет для пары multiseat-станций с сервером. В данной статье не рассматривается.

Всегда странно представлять себе времена, когда чего-то не было. Сложно сегодня представить себе, как мы жили без персональных компьютеров, без интернета, без торрентов, mp3, или без электрокопировальных аппаратов, в просторечии «ксероксов». Тем не менее всегда были времена, когда что-то привычное нам еще не существовало. Также обстояло дело и с понятием «снэпшота данных». Но сперва — что же такое «снэпшот»?

"Снэпшот" (дословно — «фотография», «моментальный снимок», здесь и далее под этим словом мы будем понимать конкретно, не уточняя, «снэпшот данных») это моментальная копия состояния данных в системе хранения, или программе, зафиксированная на определенный момент времени. Это может быть моментальное состояние содержимого файла, базы данных, или файловой системы (как частного случая «базы данных»).
В применении к системам хранения данных этот термин появился вместе с первыми системами хранения NetApp и был, на тот момент первой и главной их «фичей».

Приветствую тебя, %habrauser%!

Предыстория:

В данный момент я работаю в небольшой конторе, которая занимается консультированием, аудитом и обслуживание в области IT. Хотя контора и небольшая, количество клиентов у нас росло быстрыми темпами, и без нормального хелпдеска обойтись было уже очень сложно. Рассмотрев приличный перечень продуктов, как платные так и бесплатные, наш выбор пал на продукт фирмы BestPractical, который называется весьма незамысловато Request Tracker.

Предисловие

Хабралюди проявили некоторый интерес к Unity, поэтому открываю этим постом цикл туториалов, освещающих основные моменты работы с объектом (цикл неопределённой пока длительности — если кому окажется полезным продолжу).

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

В свое время работая в узком кругу программистов, отдельными задачами и даже проектам, мы не задумывались о проблемах связанными с текучкой кадров. Точнее думать — думали, но ни каких мер не применяли, да и в целом коллектив был сплоченный никто не уходил и никого «не уходили». С ростом внутренних проектов и корпоративных клиентов, штат начал разрастаться и казалось, что все отлично — нас больше, значит будем больше успевать и делать, но не тут то было. Мы начали тратить кучу времени на “бесполезные” обсуждения, проверки, излишние проектирование и т.д, больше всего раздражает — это проверка кода. И тут я начал думать, что “мудрые и древние” наверняка решали эти проблемы с сотнями, тысячами программистов, неужели мы не справимся? Я решил провести эксперимент, под названием “автоматизированная проверка стиля кода при комитах”. Для большинства из Вас это не новость и наверняка вы этим пользуетесь, но поделиться опытом внедрения думаю, не будет лишним.

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

Не секрет, что в современном мире без продуктов Microsoft практически не обойтись. Однако во многих случаях получается так, что гораздо эффективней использовать на рабочих компьютерах системы на базе GNU/Linux, а не Windows. Это значительно упрощает администрирование и сокращает расходы, предоставляя при этом пользователям гораздо больше легкодоступного функционала. Но что делать с теми приложениями, которые работают только под Windows и которым нет подходящего аналога в мире Linux? Поскольку обычно таких приложений единицы (иначе просто нету смысла ставить Linux на рабочий компьютер), то разумным выбором может стать использование терминальных серверов, работающих под серверными ОС от Microsoft. Кроме того, Linux лучше всего подходит для любых тонких клиентов, поскольку адекватных версий Windows для них просто не существует.

В любом случае необходимо уметь подключаться к терминальным серверам Windows. Для этого в MS был разработан свой протокол удалённого рабочего стола — RDP. Однако до недавнего времени для Linux существовал единственный открытый клиент для работы с этим протоколом — rdesktop. К сожалению, его развитие давно остановилось, и он испытывает огромные трудности при взаимодействии с современными версиями Windows.

Но недавно тихо и незаметно проект rdesktop был форкнут, в результате чего на свет появился новый открытый RDP клиент — FreeRDP. Первый же релиз этой программы разом исправил большинство известных проблем rdesktop, и проект продолжает активно развиваться. Почему-то появление столь полезного приложение обошли вниманием, поэтому я и решил опубликовать этот пост, чтобы хоть как-то исправить эту ситуацию и рассказать всем о существовании нормального RDP клиента для Linux. Под катом — описание возможностей FreeRDP и немного про отличную графическую оболочку Remmina для него.

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

В топиках про немецкий хостинг от Hetzner и Server4You (кстати, у последней компании есть ещё несколько сайтов – будьте аккуратнее) люди интересовались, а почему именно хостинг в Германии? То, что не в России мы теперь уже знаем точно, и если у проекта в целевой аудитории центральная и западная Россия и/или Европа, то выбор немецкого хостинга часто оказывается оптимальным по соотношению цены/качества/пинга. Однако, если ваш проект нацелен на США или на весь мир? Думаю, что хостинг от Hetzner тут подходит довольно слабо — эта компания, как и почти все немецкие хостинги ориентируется в основном на внутренний рынок, не заботясь ни о доступности серверов вне страны (очень часто в случае с Hetzner пинг в Россию или вообще доступность сервера из России оказывается под вопросом), ни о хорошей международной поддержке хотя бы на английском языке (у Hetzner сейчас эту проблему, решили и саппорт доступен на английском, что далеко не всегда так в случае с другими немецкими хостерами – очень часто и сайт и саппорт на немецком языке). Для сервиса ориентированного на самый прибыльный – американский сегмент желателен и хостинг американский и возможность «роста».

Т.к. наша компания уже практически год является клиентом одного из американских VPS-хостингов (открываем там небольшой бесплатный хостинг картинок — можно попинговать и всячески проверить работу), хочу рассказать про него, сделав некоторые сравнения с хостингом немецким (да простят хабражители, за сравнение VPS от BurstNET с опытом использования Dedicated-сервера от Hetzner – весовые категории разные, но, опыт общения с Hetzner у нас основан именно на аренде выделенного сервера).

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

Думаю, многие знакомы с весьма необычной игрой Minecraft (справа — пример сгенерированной в ней карты), в которой игрок находится на (практически) бесконечной поверхности Земли и может исследовать окружающий мир с минимальными ограничениями.

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

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

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

1. невозможно в наших условиях соревноваться с интелом или хотя бы TI в выпуске процессоров и прочих разных микросхем — цена вхождения очень высока, рынки сбыта поделены, и, по большому счету, нет необходимых знаний и опыта;
2. бессмысленно соревноваться с китайцами в производстве всевозможной массовой электроники — стоимость труда у них ниже, производственные мощности находятся у них же, рынки сбыта в руках крупных компаний;
3. можно окучивать отечественные рынки различной несложной электроникой — от сигнализаций до елочных гирлянд. Кто-то живет этим, но норма прибыли невысока, а мороки много;
4. можно участвовать в государственной программе поддержки бедных (РосПил). Отличная тема, но меня пригласить забыли.

Одна из немногих успешно работающих моделей — контрактные разработки для западных заказчиков. Идея проста: у нас заказывают наукоемкие исследования/разработки, результаты собирают вместе где-нибудь в Калифорнии (обычно по цепочке через нескольких посредников) и продают в конечном итоге какой-нибудь крупной корпорации-производителю электроники. Тому же Интелу, к примеру. Года через 2-3 все это возвращается к нам в составе сложных агрегатов (телефонов, мониторов и т.д.) в красивой коробке с клеймом “Made in USA” (что редко) либо “Made in China” (значительно чаще) по червонцу за пучок. Ситуация с одной стороны грустная — мы не владеем технологической цепочкой, а способны решать лишь отдельные задачи. Но есть и основания для оптимизма — таким образом российские разработчики входят в общемировую систему и получают ценный опыт. Компания, в которой я работаю, специализируется в основном на исследовательских разработках в области беспроводных коммуникаций. Исходя из этого я и буду вести дальнейший рассказ.

Как же выглядит процесс разработки?

Как известно, все люди делятся на два вида: те, кто ещё не делает бэкапы, и те, кто их уже делает. У тех, кто только начинает делать бэкапы, первым обычно встаёт вопрос о том, каким способом архивировать данные. Простые варианты (вручную нарезать болванки, целиком архивировать каталоги на другие серверы) рассматривать не будем — у них весьма скромные возможности по индексированию и поиску архивных файлов. Вместо этого обратимся к автоматическим системам бэкапов, в частности bacula. Данная статья не рассматривает вопрос, почему bacula. Главные причины — она распространяется под свободной лицензией, доступна для кучи платформ и обладает огромной гибкостью.

Второй вопрос после выбора системы архивации — выбор места, где хранить бэкапы. Bacula позволяет использовать стриммеры, компакт-диски, писать архивы в FIFO-устройства и в обычные файлы. Стриммер удобен на корпоративных серверах, где есть постоянный физический к железу. Хранение архивов в файлах подойдёт, когда объём архивов не превышает объёма жёстких дисков, плюс для надёжности хранения желательно делать RAID-массив с избыточностью, а то и несколько физических серверов для бэкапов, желательно в разных помещениях. Иначе всё это до первого пожара. Нарезать на болванки — это домашний вариант, главный недостаток которого — необходимость регулярного втыкания свежих дисков. Мы же настроили bacula для архивации данных на Amazon S3.

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

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

Приветствую, хабровчане!

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

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

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

К счастью, решить большинство этих проблем в Linux может технология LVM. Она создаёт дополнительную абстракцию — логические тома, которые видны в системе, как обычные разделы, однако реально ими не являются. Эта технология очень полезна для серверов, однако и на домашних компьютерах она приходится очень к месту. Я больше не думаю, какого размера диск выделить под систему, чтобы какой-нибудь texlive не забил бы всё место, но и чтобы лишние 5 — 10 гигабайт не пропадали просто так. LVM имеет ряд существенных преимуществ, значительно упрощающих жизнь:

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

Прелюдия

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

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

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