*Местами используются стоковые фото, по причине отсутствия своих в надлежащем качестве. Осторожно! На фото присутствует ковер, коврофобам не смотреть :) Очень много больших фото, трафик!

Приветствую! Как и обещал, расскажу о том как я мощник для акустики собирал. Так как промышленные варианты меня не устраивали, я нацелил свой выбор на diy варианты. Усилитель будет использоваться с полочной высокочувствительной акустикой, я решил что буду собирать усилитель мощностью 15-30 ватт, обязательно в A классе ( Да, да, вместо обогревателя ). Перебрал очень много проектов, остановился на клоне Krell KSA 50 — HifiDIY A20. Он полностью меня устроил, мощностью, габаритами, комплектующими. И я принялся за сборку.

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

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

Эпоха тёплого лампового WEB 1.0 давно прошла, и в последнее время мы имеем дело со страницами, которые кишат так называемой динамичностью. Динамичность может быть обеспечена при помощи JavaScript, VbScript и плагинами вроде Java, Flash, Silverlight. В этой статье я хочу затронуть одну из возможных оптимизаций web-сайта — объединение всех javascript файлов в один.

Зачем?

Основных причин две:

1. Повышение скорости загрузки страницы.
2. Снижение нагрузки на сервер.

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

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

Здравствуйте, хабровчане!
Совсем недавно я озадачился попробовать css3-плюшки в действии. Посмотреть на что они годны в реальности. Мой взор пал на знакомые всем галереи fancybox и т.д. Другими словами — решил сделать подобие js-галереи, но только на чистом html+css.

Итак, у вас есть чистая Ubuntu, в консоли открыто ssh-соединение с сервером и консоль вас заманчиво приглашает — «root@my-awesome-host:~#» — и больше ничего нет. А хочется запустить и показать всему миру какое-то рельсовое приложение. Поехали от супа до орехов.

Ruby позиционирует себя как «programmer's best friend», как великолепный язык программирования, как замечательный скриптовый язык, как отличное средство для разработки веб приложений. Всякий знает, что Ruby — это очень приятный язык с очень активным и дружелюбным сообществом. Однако не все знаю, что это сообщество так дружелюбно, что позаботилось не только о коллегах — программистах разрабатывая множество полезных gem'ов, но и о детях разработав для них несколько очень интересных и полезных инструментов.

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

Эта статья является изложением в письменном виде моего личного восприятия программирования и Объектно-ориентированного программирования в частности. Здесь собраны и душевные негодования, и переживания за программистов всего мира. Всё, конечно же, подкреплено исходным кодом.

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

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

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

Несколько книг по разным темам, которые находятся в открытом доступе.

Основы программирования

• codebetter.com/karlseguin/2008/06/25/foundations-of-programming-ebook
• pine.fm/LearnToProgram
• netlib.bell-labs.com/cm/cs/pearls
• www.faqs.org/docs/artu
• savannah.nongnu.org/projects/pgubook

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

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

Итак. Есть программа с папкой DATA, данные из которой очень хочется получить.

Есть несколько вариантов.

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

Для начала нужно узнать в каком формате хранятся данные в программе. Можно воспользоваться бесплатной программой TrID.

Как то поздним вечерком мне пришла мысль изучить Backbone.js и привязать его к уже написанному на jQuery сервису. Сервис уже серьёзно расширился и меня достало это нагромождение обработчиков кликов, запросов и логики. Поэтому, я как усердный школьник полез в официальную документацию. Но либо я тупой, либо мой английский меня подкачал, либо то и другое вместе, но я не черта не понял. Я прочитал уже второй раз, внимательно, и для особо одарённых мест использовал google translate. Прочитал также и пример ToDo List. Всё показалось понятно, ровно до той поры пока я не стал писать. После чего я взял всё что нашел по этой библиотеке, как на английском так и переводы. Прочтя кипу документации я решил, что сейчас вроде всё понял. Я напрягся, но… Не вышел каменный цветок у мастера Данилы, т.е. вышло, но это явно был не цветок, и камень как то неправильно пах. Тогда, как прилежный ученик, я решил написать «Hello, KittyWorld» с нуля. Попутно комментируя и сохраняя шаги в hg, у меня получилось введение в backbone.js framework для таких как я, особо одарённых.

Как-то обеспокоился наличием собственного FTP-сервака. Тем более под это дело «на помойку» был отдан комп этак десятилетней давности. Так как я человек хоть и виндовый, но начинал с чистого ДОСа (про книжки тов. Фигурнова кто помнит?), то я решил сделать все на линуксе. В линуксе я был ноль полный. Еще и усложнил задачу — только консоль, никаких исков (как же — это ж линукс). Дистрибутивом был выбран Debian. Так получилось, что надобность в 2Тб личном хранилице отпала через год и комп был отдан в хорошие руки, а хард пристроен в нужное место. Но был накоплен неплохой опыт стопроцентного новичка. Какие только глупые ошибки я не совершал поначалу! И хабр читал, между прочим, пока разбирался с проблемами. Поэтому эту свою дебютную (первую) статью на хабре я посвящаю тем, кто хочет заняться линуксом с нуля и эта статья призвана для плавного ввода «в тему», являясь, по сути, фильтрацией и систематизацией всего того, что я нашел на просторах интернета. Ранее я этот материал уже публиковал, но, думаю, на хабре он тоже будет полезен.

Привет, %хаброюзер%!

Сегодня я поделюсь с вами своим опытом прохождения собеседований на вакансии PHP-программиста в «белокаменной»Москве.

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

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

Известные

• Yet another Conference от Яндекс 2010 2011 — раз, два, три
• Application Developer Days
• DevPoint
• HighLoad++ Последние видео за 2009 год, но вроде как обещали выложить с недавно прошедшей
• РИТ
• JavaTechDays 2010, 2011
• DevСon'11
• Percona.TV Видео по MySQL
• PyCon — 2009-2011

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

Недавно анонсированный бесплатный онлайн-курс Стэнфорда по основам искусственного интеллекта вызвал настоящий ажиотаж у публики. Заявки на регистрацию подали уже 81 966 человек. Оно и понятно: курс ведут Питер Норвиг и Себастьян Тран — настоящие звёзды. Первый раньше работал в НАСА и написал учебник по ИИ, а второй разрабатывает лучшие в мире роботизированные автомобили (для Google).

Очевидно, что качественное образование через интернет нужно людям и становится всё популярнее. Поэтому перед началом учебного года есть смысл напомнить список 13-ти бесплатных учебных курсов Stanford Engineering. В отличие от лекций Норвига и Трана, это не онлайновые, а старые курсы. В свободный доступ уже выложены видеозаписи всех лекций от первой до последней, PDF'ы с заданиями и другие материалы, но здесь нельзя задать вопрос преподавателю.

Любой приказ, который может быть неправильно понят, понимается неправильно (Армейская аксиома)

Редкий скрипт лишен необходимости общения с пользователем. Мы ожидаем, что программа (утилита) будет выполнять то, что нам от нее хочется. Следовательно, нужны инструменты влияния на них, да и программа сама должна объяснить, как продвигается ее работа.
Данным топиком я хочу рассмотреть несколько способов взаимодействия bash-скриптов с пользователем. Статья рассчитана на новичков в скриптинге, но, надеюсь, люди опытные тоже найдут что-нибудь интересное для себя.

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

Итак, грехи:

1. Медлительность
2. Блокирующее взаимодействие
3. Неуместные ограничения
4. Ненастроенность
5. Несамостоятельность
6. Забывчивость
7. Гордыня

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