Pull to refresh
30
0
Send message
Я неделю назад что-то такое слепил из защитных очков, прозрачного листа A4 и 3M-овских липучек для картин.

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

Естественно, требуется наличие подходящих очков, но не нужен 3D-принтер.
Можно заменять листы или разбирать и собирать эту конструкцию для чистки.
Пространства внутри достаточно, чтобы носить маску или респиратор.

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

«Crusader: No Remorse» (1995), «Crusader: No Regret» (1996) > Link.
В своё время была вполне передовая игра.

И то, что игрушку обсуждать интереснее, чем проблемы SO/SE уже показательно.
Изначально SO привлекал много энтузиастов заинтересованных в качественных вопросах и ответах. Саморегуляция с оценками ± вполне справлялась с задачей контроля качества контента.
Года через три проект стал массовым, средний энтузиазм по больнице упал и качество (без дополнительных/новых механизмов контроля) пошло на спад.
Сейчас SE/SO все еще пытаются положить основную нагрузку на самомодерирование силами community, но в отсутствии четкой цели и понимания требуемых механизмов контроля — колбасит их не по-детски. Дай бог lawsuit'ы смогут пережить.
Угу. То есть то, что автор, сконцентрировавшись на построении прямой, пришла к неправильному ответу вас не смущает. *sarcasm*

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

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

Интересно, что это было за интервью.
Навскидку могу сказать про ветки в hg — commit содержит имя ветки, соответственно принадлежность commit'а к ветке однозначна. Ветка в git'е это блуждающий указатель на commit — после разветвления или мёржа о том в какой ветке были созданы «старые» commit'ы можно только догадываться. Tag'и в git'е — это только метки/указатели на дерево истории; в mercurial — установка tag'а это тоже часть истории. В целом, hg несколько более формализован а git несколько более гибок — соотвественно hg дает чуть больше шансов понять что, где и как изменялось, а git несколько меньше путается под ногами.
Shapelez, спасибо, конечно за аттачмент, но я именно это и написал. Срок начала приема заявок на графике — 31.03 а не 14.04, как написано в первых строках статьи; 15.05 — срок завершения работ, а не просто окончание приема заявок. Кроме того, если у кого-то есть желание поработать в режиме хакатона (то есть довести идею с нуля до работоспособной POC), то хорошо было бы видеть весь этот анонс не 29.04 a хотя бы 07.04.
14 апреля начался сбор заявок (и будет продолжаться до 15 мая) на участие в Виртуальном хакатоне от компании Microsoft...

На самом деле дальше в статье говорится, что сбор заявок начался 31 марта, а 15-17 мая уже срок сдачи решений.

«Анонс» через месяц после начала конкурса и когда половина времени на работу прошло — это как-то… грустно, что ли?
Огромное спасибо за ссылку на блог Josh Varty. По Roslyn пока не так много удобоваримой и up-to-date справочной информации.
Спасибо за статью — интересная точка зрения.

У меня, правда, на первом месте удобство и компактность (плюс backup возведенный в привычку). Так что при всем многообразии выбора в конце концов выбор останавливается на micro SD адаптере для USB, например

image
Спасибо за статью. Мне очень нравится Ваш подход — обязательно использую в своих проектах.
Американизм, скорее всего будет makeshift или make-do. Есть еще более красивое «improvised». Как вариант — Make-Do It Yourself — #MDIY.
В первом варианте фривольно-неформальная формулировка невольно заставляет усомниться в серьезности отношения к своим обещаниям. В последнем варианте построение фраз суше и бюрократичнее, но более привычно для «серьезных» документов, что, скорее всего, и вызывает больше доверия. Можно было б попробовать пойти до конца, убрав чересчур оптимистичные 100%, например "The privacy of the customers is our major concern. You information will never be shared with any third party.", а для a/b сравнения поставить типичное для реклам "We guarantee 110% privacy!"
Если не жалко — то однозначно поделиться! На мой взгляд, здесь самое интересное — это процесс заказа корпуса и оформление спецификации на него.

Еще, конечно, уникальное решение с блоком питания. Хорошо это или плохо с точки зрения безопасности можно обсуждать, но как дизайнерское решение — просто очаровательно. Сразу руки чешутся заказать или попробовать собрать себе такой же.

С антеннами wi-fi закрывающими аудио гнезда, пожалуй, единственный недочет. Логичнее было бы если б они закрывали гнездо ethernet. Хотя, расположение гнезд привязано к существующей материнке, что и определяет… откуда ноги растут. В качестве бредовой идеи — интересно, насколько сложно антенну встроить в корпус? У Lenovo, например, есть подобное решение с антенной вокруг экрана лаптопа.
Во время написания статьи наткнулся на Dependency Property Generator. Надеюсь это тоже будет экономить время.

propdp <Tab> <Tab> как-то проще — не надо никуда из студии переключаться.
Вопрос поставлен правильно, конечно.

Основные черты отличичающие Kiln от конкурентов — действительно удобные code review, родная интеграция с FogBugz, ну и поскольку Kiln изначально нацелен на компании с большим числом проектов — развитое управление доступом к репозиториям. Про остальные функции писать не буду — кроме одновременной работы с Git+Hg они (на мой взгляд) достаточно похожи на другие хостинги кода — какие-то более удачные, какие-то менее.

В роли «еще одного бесплатного хостинга на микрокоманду из 2х человек» у Kiln'а тоже остаются свои плюсы, например быстрый поиск и продуманный web-интерфейс к данным DVCS. Да и если эти 2 человека не в одной комнате, то ревью тоже помогают — как минимум получаются плюсы от pair programming, но в более offline-овом режиме — без отрыва других людей от продуктивной работы.

Собственно, вопрос «Зачем?» превращается в «Сможет ли Ваша команда выгадать за счет этого?»
Да, это вольный «частичный перевод Kiln Harmony Internals: the Basics» на который я сослался. Проблема в том, что там явно прописано отсутствие у Kiln'а бесплатных аккаунтов. Меня бы такое сразу оттолкнуло от экспериментов — зачем пробовать что-то еще если есть уже bitbucket и github.

Собственно, из-за той статьи и возникло желание написать про возможность использовать Kiln нахаляву и просуммировать его сильные стороны — может быть кому-нибудь пригодится.
Да, точно. Я, похоже, погряз в деталях внутреннего устройства Git'a и Mercurial'а и не сразу понял что Вы хотели сказать.

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

Закладки Hg более легковесны чем ветки, при этом активные закладки ведут себя как heads в Git'е. Так что — Вы правы — их удобно использовать с той же целью.
Bookmarks в Mercurial это lightweight-tag в Git'е: оба содержат только имя для коммита и ничего больше.

«Ветки» Git'a, это, скорее, heads — соответствуют heads в Mercurial. Одна ветка в Mercurial может иметь несколько голов, хотя обычно этим не злоупотребляют.

Там еще много интересных отличий. Например, изменение тэгов в Mercurial входит в коммит и отслеживается в дереве истории, тогда как в Git'е для сохранения информации о дате и авторе ярлыка надо сделать tag c описанием (annotated и/или signed), но в граф истории создание/изменение тэга не включается.
hg update {revision} (он же hg up, hg checkout, hg co); где {revision} может быть в том числе и веткой.
«Идеальное устройство» это или беспиксельное устройство, или экран с очень высокой (бесконечной) плотностью пикселов и, соответственно, с возможностью показывать шрифт без искажений вызванных особенностями устройства. Из реальных к этому, наверное, ближе всего принтеры.

«Идальный» режим рендерит текст без учета существования пикселов.
Если линия в символе по толщине совпадает с одним пикселом, она может быть спозиционирована точно на пиксел или с дробным смещением, например в пол-пиксела. В первом случае будет четкая линия на экране, во втором — две линии в соседних пиксельных колонках, как в буквах N, l, m во второй строке на скриншоте.

MS долго настаивала, что вся отрисовка такста в WPF должна быть «идеальной», так что на мониторах на шрифты среднего и мелкого размера было страшно смотреть.
В WPF 4 добавили поддержку четкой отрисовки на обычных дисплеях и возможность выбора режима через TextFormattingMode с двумя возможными значениями — Display и Ideal.
1

Information

Rating
Does not participate
Registered
Activity