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

Сам я являюсь RubyOnRails разработчиком, вследствие чего для небольших проектов стараюсь использовать стандартную конфигурацию, которая использует SQLite. Не вижу смысла тянуть в зависимость простого приложения тяжеловесные СУБД.

О чем эта статья

Сегодня я расскажу про библиотеку Boost Signals — про сигналы, слоты, соединения, и как их использовать.

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

Каждый уважающий себя советский мальчишка должен был: знать, где найти карбид; быть влюблен в Алису Селезневу; хотеть стать космонавтом. Я в этом плане не исключение и, так сказать, полностью соответствовал. Со временем многое изменилось, но интерес к космосу остался. С января 2004 года я в течение полутора лет практически ежедневно заходил на специальную страничку НАСА и смотрел, что нового произошло с марсоходами. Так что документальный фильм «Смерть марсохода» (Death of a Mars Rover) был изначально обречен на ошеломительный успех среди меня.

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

"

Большинство своих предыдущих статей я писал со стороны ИТ специалистов и компаний (Как отпугнуть высококлассных специалистов. Руководство для компаний, Разбор полетов: как нужно описывать вакансии, Когда я говорил...), сегодня же хочу взглянуть на процесс выбора исполнителя глазами заказчика.

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

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

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

Ни для кого не секрет, что проектирование структуры БД является одной из основных и порой очень трудозатратных задач при разработке любого ПО, работающего с данными. Все мы так или иначе проектируем БД, пытаясь представить себе схему взаимосвязей таблиц, а зачастую рисуем, визуализируем структуру БД, прежде чем перенести ее в СУБД. Для моделирования баз данных MySQL есть MySQL Workbench, поставляемый разработчиком, для MS SQL есть Database Diagrams; я до недавнего времени пользовался Dia, а кто-то, может быть, использует для этих целей MS Visio. Но для PostgreSQL я не встречал ни одного адекватного решения, которое позволяло бы максимально просто и точно перенести наброски структуры БД в код ее создания в самой СУБД.

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



Итак… (текст, много картинок)

Все чаще приходится слышать: "Работай на результат!"

"Работай на результат!" — кричит начальник подчиненному, чтобы заставить этого тупого неповоротливого кретина, принятого в команду по протекции, приносить хоть какую-то пользу общему делу.

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

"Обязательна ориентированность на результат!" — напишет пожилая кадровичка «ГорАвиаВагонМорСтроя» в требования к кандидату на должность помощника бухгалтера, будучи уверенной в том, что раз все так пишут, то и ей надо.

"Наш девиз — Работа на Результат!" — именно так, с двумя Большими Буквами для большего пафоса пишет на корпоративном сайте очередной говноконторы-однодневки молоденькая девочка-всё-в-одном, гордо именующая себя помощником руководителя по связям с общественностью. И этот самый руководитель, даже не знающий, что секретутка это, оказывается, ни больше ни меньше, целый его помощник, тоже употребит эту фразу на фуршете в городской администрации с целью создать себе рекламу в среде местных бюрократов.

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



А хуже ли?

От переводчика: Недавно презентовал на Хабре один проект, в котором использовал MySQL. Многие пользователи удивлялись, почему я не использую NoSQL для моих задач, и настоятельно порекомендовали переходить на нереляционные базы данных. Сегодня я наткнулся на эту статью, которая отлично объясняет, почему я “боюсь” NoSQL.

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

Последние две недели, однако, заставили меня понять, что я больше никогда не начну проект на основе MongoDB или любой другой нереляционной базы данных (НРБД) в качестве первичного хранилища данных. Обратите внимание – я сказал “начну”. Я не говорю, что больше никогда не буду использовать MongoDB как таковую.

^{Бизнес-ангел часто смотрит на стартаперов с недоумением}

Предположим, вы придумали какое-то железо, и теперь хотите начать его производство. У вас уже есть прототип: вот он, в руке, коряво выглядит, в 4 раза больше нормального размера и из него торчит провод. Но он работает. У вас горят глаза: ведь осталось только «допилить» его и начать производить по всему миру. Из маркетингового плана у вас есть только «запостить про железку на Хабр – и всё закрутится».

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

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

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

Добрый день, уважаемые хабровчане. Представляю вашему вниманию статью, в которой я описываю процесс проектирования и создания шестиногого робота полностью с нуля. Вы не найдете здесь надоевших всем ардуин и готовых наборов «хексапод за 5 минут». Из-за большого объема информации, статья будет состоять из нескольких частей, описывающих разные этапы проектирования и освещающих грабли, на которые я наступал в процессе оного.
Итак, встречайте – Ectognathus.

Узнав, что я занимаюсь разработкой мобильных приложений, мои знакомые время от времени, спрашивают: «сколько стоит разработать приложение?». И я честно отвечаю: «от 200 долларов». Приложение будет писать на экране HELLO WORLD, его не пропустят в магазин из-за «bad user experience», но работать-то приложение будет!

Самое удивительное, что огромное количество разработчиков и вправду создает что-то за 3000 долларов и даже выкладывает это в App Store.

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

Так и хочется, заглянуть им в глаза и проникновенно спросить:

— Ребят, а вы из какой сказки?

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

Основные статьи расходов при создании проекта:

Статья	Расход
Дизайн приложения	$ 13 000
Создание уникальности	$ 10 000
Производство графики	$ 35 000
Программирование	$ 45 000
Текстовый контент	$ 5 000
Локализация	$ 3 000
Музыка и звук	$ 1 000
Полировка	$ 17 000
Маркетинг	$ 30 000
Управление	$ 30 000
Итого:	$ 189 000

Вся раскладка будет сделана на примере нашего приложения "МоиЭмоции". Приложение бесплатное, весь функционал можно посмотреть.

Хочется поделиться с хабросооществом информацией о том как я собирал домашний сервер.



Из софта на домашнем сервере будет «крутиться» следующий набор:

• torrent клиент с web-мордой
• DHCP — раздаем ip адреса и сетевые настройки
• TFTP — для сетевой загрузки
• OpenVPN — для хождения в сеть с нетбука из недоверенных сетей
• FTP/Samba/NFS — сетевые шары для доступа с домашних машин
• Radius — для WPA2 авторизации
• DigiTemp — мониторинг домашней температуры

Привет, Хабр! В ходе обсуждения одной статьи про «идеальную» домашнюю сеть, возник спор, что лучше, аппаратный NAS или мини-компьютер с Linux дистрибутивом. Автор предлагал использовать аппаратный NAS, т. к. якобы он проще в администрировании, не требует знаний Linux, да и вообще NAS тихий. Но при этом, для просмотра на DLNA-телевизоре видео, который он не поддерживает, предлагал включать ноутбук с транскодирующим DLNA. Меня это, мягко говоря, удивило, т. к. в идеальной сети такого быть не должно. Поэтому хочу представить своё видение одного из ключевых компонентов домашней сети — централизованного хранилища данных, и основано оно будет на мини-ПК с ОС Ubuntu Server.

Почему-то Яндекс не объявил в своем блоге на хабре, что видео с леций третьего набора их КИТ выложено в свободный доступ. Всего 7 докладов.

• профессии в мире информационных технологий;
• инструментарий системного инженера;
• архитектура операционной системы;
• безопасность информационных систем;
• организация хранения данных;
• виртуализация в Linux;
• компьютерные сети; (+ продолжение)

Под катом планы лекций.

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

Сегодня рассмотрим менее экзотический сценарий использования ключевого слова volatile.

Среды разработки С++ для Ubuntu

При переходе на Ubuntu первой задачей был поиск удобной среды разработки.
Перед выбором выступили такие кандидаты: Code::Blocks, Netbeans, Eclipse, Anjuta.
Продолжение под катом.

В интернете довольно много говорят о новых возможностях C++11: auto, lambda, variadic templates. Но как-то обошли стороной новые возможности работы с исключениями, которые предоставляет язык и стандартная библиотека.

От предыдущей версии стандарта остался механизм генерации исключений (throw), проверка того, что мы находимся в процессе обработки исключения (std::uncaught_exception), механизм остановки, если исключение не было обработано. Также есть иерархия стандартных исключений на базе класса std::exception.

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

Это перевод статьи «How to trick C/C++ compilers into generating terrible code?», автор оригинала — Aater Suleman.

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