Некоторое время назад я публиковал статью о самодельных микропроцессорах, сегодня же мы затронем более сложную и щекотливую тему (особенно в свете событий на Фокусиме) – создание ядерного реактора, способного генерировать энергию в домашних условиях. И перед тем как вы начнете волноваться, вспоминая о негативных опытах в прошлом (см. Радиоактивный бойскаут – наковырявший прилично амерция-241 из детекторов дыма) заранее скажу, что все что описано в этой статье – относительно безопасно (по крайней мере не опаснее работы с фтороводородной кислотой дома), но крайне не рекомендуется к повторению. Перед любыми действиями проконсультируйтесь со своим адвокатом — законы разные в разных странах. Много кто уже сидит.

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

7. Производительность скалярных UDF оставляет желать лучшего

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

Посмотрите этот пост о принудительном использовании параллелизма – в частности, список того, что приводит к генерации «однопоточного» плана выполнения запроса. Скорее всего, использование скалярных UDF (прим. переводчика: а для серверов младше 2008 R2 и не только скалярных) приведёт к тому, что ваш запрос будет выполняться в одном потоке (*грустно вздыхает*).

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

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

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

В определенный момент мне стало некомфортно использовать стандартный контрол WebBrowser, предлагаемый Visual Studio.
Причин было несколько:
1. Использовался IE-движок, что само по себе уже сильный аргумент.
2. Кривая работа с JS.
3. Отсутствие масштабирования.
4. Если запустить на машине, где стоит IE6, то все его «достоинства» переносятся на приложение.

В итоге был начат поиск альтернативных решений.
Было рассмотрено 2 SDK. xulrunner(Mozilla) и Awesomium(Chrome)

Подключение обоих происходит примерно одинаково, но на всякий случай опишу оба.

Часто ли уходя за очередной чашечкой кофе или выйдя из кабинета/офиса совершить личный звонок, ты ловишь себя на мысли что забыл заблокировать экран своего компьютера? А на компьютере в это время осталась открытая переписка в Skype/почте или еще хуже — сессия root'а в консоли? В результате ты стараешься вернуться к своему компьютеру как можно быстрее, чтобы добрые коллеги не успели поставить фоном рабочего стола обои с Черным Властелином.
В данной статье приведу пример решения этой проблемы с блокировкой экрана, которое поможет закрыть доступ к рабочему столу в тот момент когда ты отойдешь от компьютера.

Статей по пониманию IPv6 написано предостаточно для всех категорий: от пользователей до провайдеров и если пользователю с «правильным» dual-stack провайдером нужно просто включить устройство, поддерживающее IPv6, то что делать провайдеру с его IPv6-блоком не ясно. Попробуем в этом разобраться. Статья подразумевает что читатель умеет считать маски IPv6, большего не требуется.

С тех пор, как мы анонсировали нашу программу разработки MarvDev несколько месяцев назад, нам посчастливилось пообщаться с несколькими сотнями разработчиков, ищущих партнеров для издания своих игр.

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

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

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

Итак, что же замедляет разработку программного обеспечения?

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

И почему раньше задачи решались так просто, а теперь выглядят запутанными и сложнореализуемыми?

Казалось бы, положение должно улучшаться, ведь Вы уже давно в проекте, разве нет? Почему всё происходит наоборот?

Коучинг не учит, а помогает учиться.

Тимоти Голви

Мы можем учиться, учиться учиться,
может быть, учиться учиться учиться.

Грегори Бейтсон

Грегори Бейтсон — один из наиболее влиятельных мыслителей нашего времени (по мнению Фритьофа Капры, «Дао физики»), работы которого соединяют знания из эпистемологии, кибернетики, антропологии, психологии, экологии. Одним из самых фундаментальных концептов Бейтсона является идея о логических уровнях обучения и коммуникации.

Основание ее лежит в теории логических типов Бертрана Рассела, которая коротко может быть изложена следующим образом: все объекты мышления организованы в своеобразную иерархию, к нулевому типу которой относятся индивидуальные объекты (например, ложка). К первому типу относятся множества объектов нулевого типа (например, ложки как множество); ко второму — множества множеств этих объектов (например, «столовые приборы» как множество, которое объединяет ложки, вилки, ножи и другие приборы) и т. д. Таким образом проводится строгое разграничение между предметами, свойствами предметов, свойствами свойств предметов и т. д.

Не так давно Стивен Синофски (экс-вице-президент подразделения Windows в Microsoft) начал вести свой блог, в котором он делится мыслями о продуктах, продуктовой разработке и управлении.
Мы с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.

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

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

Естественное напряжение (sic!)

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

Но кому нужно это «организованное напряжение»? Даже когда вы просто делаете, то что должно, вам и без того хватает стресса — зачем добавлять новый, от которого к тому же никак нельзя будет избавиться?

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

Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

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

Весьма красочно иллюстрирует размышления на тему шифрования изображение с xkcd.com.



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

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

С течением времени изменяются наши представления о способах взаимодействия с компьютером. На смену «классических» клавиатуры и мыши, в нашу жизнь прочно вошли тачпады и сенсорные экраны. Но это не последняя ступень эволюции для средств ввода информации. С появлением устройств дополненной реальности, например таких, как Google Glass, возникает необходимость в интерфейсах способных гармонично вписываться в данную концепцию. Предпосылки к возникновению таких интерфейсов имеются, так, например, появились такие устройства как Intel Creative Camera, Microsoft Kinect или Leap Motion. Основными управляющими элементами в данных устройствах являются руки пользователя. Поэтому, одной из фундаментальных алгоритмических задач, для взаимодействия с подобными устройствами, является детектирование рук и пальцев пользователя и реконструкция их пространственного расположения.
В данной статье речь пойдет о одном из способов решения задачи детектирования ладоней и пальцев.

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

Расчет себестоимости

Говоря о стоимости создания сайта, начать необходимо с определения его внутренней себестоимости в самой компании. До сих пор многие студии работают по фиксированным тарифам (сайт-визитка – XXX рублей, интернет-магазин – YYY и т.п.). Но, так или иначе, все агентства продают время своих сотрудников, и определение себестоимости должно отталкиваться именно от этого фактора.

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

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

• ФОТ сотрудников – 50%
• — Производящие ресурсы (30%)
• — Менеджеры, обслуживающий и административный персонал (20%)
• Условно-постоянные расходы – аренда офиса, канцелярка, расходники, еда, техника и пр. – 15%
• Налоги – 20%
• Маркетинг и реклама – 15%

«Право налогоплательщика избегать уплаты налогов с использованием всех разрешенных законом способов никем не может быть оспорено. Каждый имеет право вести свои финансовые дела таким образом, чтобы свести соответствующие платежи к минимуму…»
Дж. Сандерленд,
Судья Верховного Суда США

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

Когда в конце 80 — начале 90 мы с друзьями заканчивали институт очень многие мечтали об иммиграции. Запад тогда притягивал своей загадочностью и новыми возможностями… Среди всех стран наибольшей популярностью пожалуй пользовалась Канада. Как страна с высокой степень толерантности населения, достаточно высоким уровнем жизни, большой территорией, богатыми природными ресурсами, неплохим развитием высоких технологий и многочисленной русскоязычной диаспорой. Ну и конечно близкий к нашему климат! Многие однокурсники с тех пор уехали и в Канаду и в США и в Австралию. Вернулся только один. Из Австралии, причём без дочки и жены.
Сейчас спираль истории совершила очередной виток и я снова очень серьёзно стал задумываться об иммиграции. Подобные мысли поселились и в головах большого количества талантливой молодёжи, которой не хочется делать карьеру в силовых структурах или идти в чиновники надеясь на неплохую прибавку к зарплате в виде откатов… Риски запуска и ведения собственного бизнеса становятся выше с каждым днём, а перспективы потерять собственное дело, а возможно и свободу в одночасье все реальнее.

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

Monodroid и Monotouch это фреймворки от xamarin, которые дают возможность разрабатывать приложение на языке C# для Android и iOS соответственно. Так как это относительно новая технология информации в интернете не слишком много (за исключением офф сайта и большого количества тем на stackoverflow.com), на русском языке же я не нашел никаких туториалов и информации вообще.

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

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

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