Попробовав Svelte в личных проектах, мне захотелось двигаться дальше, и взять фреймворк в проект побольше. Для этого написал библиотеку компонентов svelte-atoms. За основу я взял UI кит на React, который используем на работе.

Каким приемам Svelte я научился, читайте под катом.

Всю свою текущую разработку я веду, используя docker контейнеры, и если под Linux такой подход не вызывает никаких проблем, то под OS X некоторые моменты могут отнять невероятное количество сил и времени.

Об одном из таких моментов я и хочу рассказать.

Вступление

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

Я, автор, Юра Перов, занимаюсь вероятностным программированием в течение уже двух лет в рамках своей основной учебно-научной деятельности. Продуктивное знакомство с вероятностным программированием у меня сложилось, когда будучи студентом Института математики и фундаментальной информатики Сибирского федерального университета, я проходил стажировку в Лаборатории компьютерных наук и искусственного интеллекта в Массачусетском технологическом институте под руководством профессора Джошуа Тененбаума и доктора Викаша Мансингхи, а затем продолжилось на Факультете технических наук Оксфордского университета, где на данный момент я являюсь студентом-магистром под руководством профессора Френка Вуда.

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

«Обычное» программирование

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

… или что такое на самом деле 'raid edition' для жёстких дисков

Немного теории

Существуют две стратегии поведения НЖМД при обнаружении ошибки:

• standalone/desktop — пытаться прочитать до последнего. Это ощущается как «тормозящий винт», который всё-таки работает, если это единичный сбой, то «затупило, но прошло», плюс характерный перестук перекалибрующихся головок.
• raid — отваливаться тут же. Это ощущается как «внезапно была ошибка диска но потом mhdd и т.д. НИЧЕГО НЕ НАШЁЛ ЧТО МНЕ ДЕЛАТЬ».

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

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

Расшифровка названия

Возможность управления поведением диска при ошибках называется очень и очень путанно: SCT ERC. Это расшифровывается как SCT Error Recovery Control. SCT в свою очередь название общего протокола SMART Command Transport. SMART в свою очередь расшифровывается как Self-Monitoring, Analysis and Reporting Technology, таким образом, полная расшифровка SCT ERC звучит так: Self-Monitoring, Analysis and Reporting Technology Command Transport Error Recovery Control (выдохнули).

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

Так вот сегодня прочитал пост "Медицина: электронные истории болезней — взгляд со стороны врача" и решил поделиться своими соображениями как программиста на возможный вариант реализации подобной системы.

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

Пожалуй, начну с того, что если перегружаться 15 раз в год, то любой «тюнинг» процесса загрузки отнимает больше времени, чем будет выиграно на перезагрузках за все время жизни системы. Однако, спортивный интерес берет свое, тем более, что люди интересуется процессом оптимизации быстродействия. А загрузка оказалась самым очевидным кандидатом в примеры того, как на мой взгляд должен выглядеть этот самый процесс. Сразу скажу, что грузиться будем с 5400 rpm винта, грузиться будем в «рабочую» систему: помимо недобитой вендорской крапвари там стоит еще куча всякого типа вижуал студии, антивируса, скайпа, стима, гуглапдейтера и пр…

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…

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

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

Мы рады пригласить вас на специальный семинар, посвященный разработке под новую мобильную платформу Windows Phone 7.
Семинар пройдет 27 сентября в московском офисе Microsoft (ул. Крылатская, 17), начало в 10:30, участие бесплатное.

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

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

В рамках семинара планируются следующие доклады:

Зачем вам это?

• Если вы знаете как делать сайт, этот метод поможет вам убедить заказчика, почему вы предлагаете ему именно этот вариант.
• Если вы заказываете сайт, то сэкономите от 2 до 10 часов объяснений что вам нужно и зачем.
• Если вы стартапер, то вся ваша команда сможет участвовать в создании нового сайта или лэндинга. Тот самый случай, когда одна голова хорошо, а команда лучше.
• Если вы учите стартаперов, то сможете помочь им выглянуть из позиции «я знаю как надо» и без сопротивления подвести их к началам CusDev-a.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

Пробовали ли вы оценивать свой IT-продукт с психологической точки зрения? Такая оценка может основываться на общей психологии и включать эргономическое тестирование, может основываться на когнитивной психологии и задействовать теорию познания и принятия решений, может основываться на теории деятельности и анализировать пользовательские сценарии, может основываться на психологии научения и бихевиоризме и анализировать продукт с точки зрения геймификации…

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

Предлагаю вариант методики для оценки IT-продукта, созданный на основе компиляции различных теорий личностных потребностей.
Тест оценивает, насколько продукт может удовлетворить 10 наиболее распространенных потребностей личности.
Этот тест можно использовать не только для оценки продукта, но и как чек-лист при поиске идей в разработке IT-продуктов.

Описание теста.
Для каждой потребности предложено по 5 вопросов о продукте.

Начал изучать NodeJS. Нигде не нашел актуальный стек мейнстримных библиотек (технологий) применяемых в node. Поэтому решил сам составить список.

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

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

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

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

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

В этой статье я хочу рассказать о командах git checkout и git reset с ключами --soft и --hard.

На Хабре уже были статьи про TestFlight (вот тут и тут), но в них речь шла главным образом про его использование и интеграцию/автоматизацию в процесс сборки. А мне всегда было интересно, как это работает изнутри:
• Как происходит сбор идентификаторов устройств? (Если вам непонятно, зачем собирать UDID’ы, пройдите по ссылкам выше)
• Как приложение устанавливается по переходу по ссылке?
• Как создается иконка на Home Screen?
• Все это хаки или легальные способы?

Если вы хотите построить свой TestFlight c блэк-джеком и всем остальным или просто интересуетесь, как сделано что-то из вышеперечисленного, – прошу под кат.

Не так давно в рамках разработки крупного ASP.NET проекта возникла следующая подзадача: реализовать визуальное отображение табличных данных, обновляющихся в режиме real-time. Схема обновления довольно проста, а именно: на сервер посредством QueryString присылаются данные, которые должны как можно быстрее заменить собой устаревшие данные на странице, причем без необходимости страницу эту рефрешить. Первым решением, которое сразу же пришло мне в голову, было использовать ставшую уже общепринятой технику AJAX-запросов по таймеру, скажем, каждые 5 секунд. Однако сразу же выявились очевидные недостатки применения такого подхода: во-первых, довольно внушительное число потенциальных клиентов, дергающих сервер каждые 5 секунд с созданием каждый раз нового соединения, а во-вторых, это все-таки довольно грубая эмуляция real-time'а, ведь данные на сервер гипотетически могут приходить даже по несоколько раз в секунду (а могут не приходить и по несколько минут, и это уже больше относится к «во-первых»).

Идея решения пришла довольно неожиданно от коллеги по работе, поделившегося линком на статью на Хабре, описывающую реализацию технологии Comet на Perl в целях создания веб-чата. "Comet — это то что нужно!", — подумали мы, и я начал разбираться, как же эту штуку можно прикрутить к ASP.NET. О чем, собственно, и пойдет речь под катом.

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

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

Tinyicon это небольшая библиотека для манипуляции с favicon сайта для передачи информации о новых событиях. Для браузеров не поддерживающих canvas счетчик отображается в title страницы.

jQuery плагин Mailcheck (github) — клиентсайд проверка емейла на опечатки по заранее определённму списку (к примеру, наиболее популярных почтовых сервисов).

Демка | сорсы демки (jsfiddle)

По заявлению (en) авторов (Kicksend), сей плагин увеличил кол-во подтверждений емейла при регистрации на 50%.