Если вы посещали блог ScottGu's Blog одного из архитекторов .net, то наверняка заметили, что его примеры кода часто поданы в странной «темной» раскраске.



Я заинтересовался и решил поискать, что это за тема такая и вот что нашел. На блоге WekеRoad раздают такую же либо похожу тему. Архив содержит файл настроек, который применяется в студии через пункт меню Tools -> Import And Export Settings... На первый взгляд очень необычно и контрастирует с остальными окнами в студии, но немного «посидев» в темной студии, начинаешь находить в этом какие-то приятные стороны. В общем, если ваш путь — темного джедая, то и темная студия — ваш выбор.

Прямая ссылка на архив с настройками.

PS: в комментариях dmx и Project86 предложили альтернативные варианты: менее контрастную тему и тему с более крупным шрифтом.

Многие СУБД поддерживают методы полнотекстового поиска (Fulltext search), которые позволяют очень быстро находить нужную информацию в больших объемах текста.

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

В статье рассказывается как работать с полнотекстовым поиском на примере БД MySQL, а так же приведу примеры «нестандартного» использования данного механизма.

Общая информация

Так как мобильных устройств существует великое множество, то одна модель может поддерживать какие-либо возможности HTML/CSS, а другая наоборот — либо не поддерживать, либо поддерживать неправильно.

Но большинство устройств среднего и уж тем более hi-end класса поддерживают HTML/CSS в той или иной степени. Таким образом, язык WML для разработки сайтов под мобильные устройства устарел и практически не используется. На смену ему постепенно приходит общепризнанный стандарт в разработке сайтов — XHTML/CSS. Кодировка — строго UTF-8 (No BOM).

Знали ли разработчики LiveScript из Netscape о том, какое влияние окажет их язык, позже переименованный в JavaScript, на лицо интернета — веб-сайты, или, может быть, они твердо на это рассчитывали, но факт остается фактом — JavaScript на сегодняшний день является одним из самых важных и распространенных языков в мире.

В то время, как на стороне сервера трудится разношерстная компания языков в лице php, perl, python, ruby, .net, java и многих других, на стороне клиента JavaScript существует буквально в гордом одиночестве. Фактически, из маленького дополнения к html, JavaScript превратился в полноправного члена банды «html+css+js», который, зачастую, уже командует остальными, сверкая золотым браслетом с надписью «ajax» и делая недовольное лицо $( ) при случае.

В качестве примера, иллюстрирующего поставленную задачу, могу привести вот этот топик: Миниатюрное приложение-калькулятор. Особенность, которую должен учесть верстальщик, заключается в следующем: окно с приложением обычно не растянуто на весь экран (зачем, например, разворачивать на весь экран калькулятор или софтфон?), но при этом размер окна может меняться пользователем, причём меняться очень даже произвольно, вплоть до полного экрана.

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

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

Я не буду подробно объяснять что такое микроблоггинг.
Меня всегда умиляло, когда люди умудряются вести блог в одной строчке статуса.
Я подумал-подумал и решил сделать микросайт, который, как и микроблог, можно запихнуть, например, в профиль.
Условия хостинга для микросайта минимальные: отстутствие php, mysql, запрет на css, но можно вставлять картинки и ссылки.
А что? нам этого хватит!
Итак, заведу-ка я свой микросайт, например, прямо тут, в комментах!
(А чтобы увидеть сайт, надо открыть комменты)
Внимание! В первом коменте устаревшая версия. Более юзабельную бету смотрите у меня в профиле (ainu)
Второе зеркало на примере коммента в ЖЖ: смотреть (не сочтите за рекламу и обратите внимание: в ЖЖ только одна запись, специально для примера)
А исходники тут.

upd: Тут второй пост о микросайтах.

В последнее время обсуждения языка PHP на хабре сводятся больше к возможностям проектировать сложные системы, что не может не радовать. Однако, просмотрев с десяток самых признаваемых веб-фреймворков (Zend Framework, Adept, CakePHP, CodeIgniter, LIMB, Symfony, MZZ и другие) я с искренним удивлением обнаружил в некоторых существенные недочеты с точки зрения элементарной оптимизации.

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

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

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

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

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

Предлагаю хабросообществу свой перевод статьи Мэттью Пола Томаса, которую он недавно опубликовал в своем блоге. Томас — программист из Новой Зеландии, работающий в команде разработчиков проекта Launchpad — детища компании Canonical, более известной как коммерческий спонсор самого популярного Linux-дистрибутива Ubuntu.
Что самое интересное:
— первый вариант этой статьи вышел еще 6 (!) лет назад.
— скорее всего появление второго варианта навеяно недавним громким заявлением основателя компании Canonical Марка Шаттлворта, в котором он предложил сообществу свободного программного обеспечения создать в течении 2 ближайших лет интерфейс операционной системы, который был бы «приятнее» Mac OS X.
— в статье прослеживается четкое разделение между volunteer designers и dedicated designers, при этом первые не пользуются у автора особой лаской. Это интересно, потому что судя по словам Томаса, он таковым и является.

Однажды мне понадобилось сделать прозрачные боковые поля для одного дизайна. Я решил использовать прозрачность CSS.

Но каково было узнать, что все элементы внутри прозрачного блока тоже становятся прозрачны и это никак не изменить :-(, тогда мне пришлось использовать прозрачный png.

Недавно я наткнулся на замечательную технику, позволяющую устранить эту проблему, ею я и хочу с вами любезно поделиться.

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

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

Статью выкладываю по разрешению автора. Оригинал здесь.

Я знаю два варианта организации времени начала работы в IT фирме и довелось мне поработать с обоими вариантами.

1. Приход на работу к конкретному времени. Сродни советскому: в 8.00 все должны быть на работе иначе штраф или даже увольнение. Уходят все в 17.00
2. Свободный приход к любому времени. Тут может быть куча вариаций, когда надо работать 8 часов в день или 40 часов в неделю или вообще никто время не смотрит, лишь бы работа делалась.

Я проработал 7 лет в компании, где надо было приходить каждый день в 9.30 и уходить не раньше 18.30, а теперь уже полгода в компании, где каждый приходит и уходит когда хочет.
И теперь я готов сравнить варианты.

Как вы думаете что вы видите, похоже ли это на привычный вам десктопный плеер:


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

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

Плюс, со все большей стандартизацией форматов файлов и все большим распостранением XML-форматов, возможность сравнения версий будет входить все больше в обиход. Возможность сравнивать документы уже есть в Microsoft Word, например.

Итак, задача. Создать возможность работать над одним документом (или группой документов) распределенной команде. Фактически, расширить SVN или CVS для нужд бизнесов, не только программистов.

Дополнительные требования:
Расширенные возможности управления правами доступа
Доступ через веб без использования локальной файловой системы
Хранение мета-данных о файлах: метки, тэги, ассоциации
Автоматическое резервное хранение

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

Схема решения очевидна:

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

Или может, кто-то знает уже готовую платформу для этого?
Кто-то пользуется Sharepoint? Можете рассказать, как это устроено у вас?

Одной из основных моих активностей на работе является оценка проектов. И в данной статье я постараюсь поделиться своим опытом в данной области.

Написание хорошего ТЗ для разработки сайта еще та проблема, и я поделюсь своим опытом по созданию «человеко-понятного» описания для заказчика для разработчика.

Посмотрите на эту страницу. Синим цветом выделены 4 плавающих блока с шириной равной 25% у каждого, которые находятся в контейнере с шириной 50px. Теперь вопрос: Какова ширина каждого блока?

Ширина эта должна быть равна 12.5px, но т.к. мы можем использовать только целые значения, то приходится округлять значения. И тут же возникает вопрос: В какую сторону округлять? В большую, в меньшую или в обе? Результаты думаю вас удивят, как и меня.


В итоге мы имеем три абсолютно разных лагеря.

— Округление в меньшую сторону — И Opera и Safari округлили значение ширины до 12px. В результате чего образовался 2-x пиксельный пробел (помечен зеленым цветом) справа от блоков. Если вы когда-либо озадачивались, почему ваша красивая навигация не заполняет все пространство контейнера, теперь вы знаете ответ.
— Округление в большую сторону — 6-й и 7-й Internet Explorer увеличивают ширину до 13px, что приводит к «поломке» структуры сайта.
— Округление в обе стороны — Firefox 2 и 3 сочетают оба подхода, округляя ширину одних блоков в меньшую сторону, а других в большую. Побочный эффект заключается в том, что ширина блоков теперь имеет разное значение, несмотря на то, что в CSS задано одно значение. К тому же, если получить значение ширины с помощью Javascript, то оно будет равно 12.5px, не давая понять в какую сторону было произведено округление. Есть и еще один неприятный момент. В Firefox 3 меняется порядок округления.

David Baron, один из разработчиков Mozilla, разъяснил ситуацию:

— Мы стараемся соблюдать все нижеописанные правила, которые, однако же, не могут быть удовлетворены одновременно:

1. 4 смежных объекта шириной/высотой 25% (например), начинающиеся у одного края внешнего контейнера, должны заканчиваться у другого. Не должно появляться никаких свободных или лишних пикселей.
2. Объекты, которые являются логически смежными, всегда должны визуально касаться друг друга. Не должно быть никаких пустых пробелов или наложений, возникающих из-за ошибки округления.
3. Объекты с одинаковой шириной должны занимать такое количество пикселей, которое было задано.
4. Границы объектов не должны быть размыты.

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

Большинство дизайнов ориентировано на использование фиксированных значений при верстке: ширина и высота блоков, размер шрифта. Это позволяет сверстанному шаблону «не разваливаться» при изменении масштабов просмотра и сохранять свойство кроссбраузерности. Однако в этом есть один большой минус – при большом разрешении экрана маленькие фиксированные блоки теряются на большой площади и остаются незамеченными. Тут даже не спасет «резиновая» верстка, т.к. сайт будет выглядеть еще более нечитабельным, например на 19'' мониторах при разрешении большем 1280 по ширине. Для меня это актуально, т.к. на ноутбуке 17'' с разрешением 1400х800 просматривать «резиновый» сайт очень неудобно. И желание оставаться на таком сайте отпадает быстро. Существует ли способ, позволяющий управлять масштабами не только текста, но и всего сайта?