+

+

Как спонсорство связано с тезисом

то вечная бета будущего RHEL

? Проект поддерживает крупная компания это показатель того, что он будет продолжительно развиваться. Если Canonical спонсирует Debian тоже коррелирует с утверждением что «Debian это вечная бета Ubuntu»? Конкретно, чем плоха система, какие вещи мешают стабильной работе?

В Fedora отдельная команда, на открытых началах как и в других дистрибутивах. RH выделяет деньги на минимально необходимые нужды, а RHEL занимаются совсем другие люди.

Fedora. Активно поддерживается компанией Red Hat, есть большинство драйверов, отличный пакетный менеджер. DE — Gnome3 + какой-то тайловый менеджер, типа XMonad, особенно если несколько мониторов.

Мы используем Closure Compiler, что в Elm, что в GHCJS позволяет сократить билд на 20-25%; на небольших приложениях 300кб Elm кода в 80кб превращается, что неплохо.

Не все так лучезарно в Elm, но достаточно хорошо. Доклады принимаются?

Самый просто вариант Compojure github.com/…​avejester/compojure#usage он отлично встанет в связке с Ring. Правда тебе придется свой Middleware сделать для обработки методов. Получишь что-то типа
gist.github.com/…​e8142dd5ec5b9902cc1cc7589

Обязательно приходи! Узнаешь о разных методах тестирования, которые можно применять и в других языках.

Имеют опыт улучшения скорости чтения по методике Олега Андреева www.fastread.ru. Там несколько этапов, материалы, можно найти в интернете. Начинал с его методик, долгое время думал, что они оригинальные. Около года назад, нарвался на ряд публикаций и несколько книжек изданных в США, в частности "Triple your reading speed " Wade E. Cutler, которая переиздается с начала 70х, которые развеяли это предубеждение.

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

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

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

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

Я лично, повысив скорость чтения в несколько раз, при этом и так довольно быстро читая, могу за неделю прочитать 2-3 тех. книги и пару фентези/фантастику. С интернетом все плохо, куча разных разметок, у каждого блога или сайта своя, особенно выводят любители держать разметку от края до края. Поэтому использую файрбаг, для ужимки до размера A4 текстовых областей, для комфортного чтения.

В байки про девочек, за 6 часов читающих полсотни книг размером с "Война и Мир", я не верю. Даже 5 книг в неделю считаю достаточно, чтобы "загрузится".

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

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

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

Надеюсь информация оказалась полезной.

В том, то и дело, что миддл не описан был=)

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

«Лучшая команда, это команда которой нет, но ее функции выполняются» =)

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

Единственная методология agile адекватно масштабируемая, это семейство Crystal от Алистера Коберна, который диссертацию на эту тему пишет. Масштабируемая по количеству участников.

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

P.S: про TDD..зря зря зря..©

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

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

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

есть только 1 проект в США с автономным подводным устройством при поддержке NASA, все остальное ROV.

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

В США есть профессия,связанная с ремонтом силовых систем, очень опасная, там подлетают на вертушках и устраняют проблемы. Такой робот был бы очень полезен, несмотря на сарказм комментарием ниже.

Так что это не сумасшедшая идея, насчет потпитки из поля разве что, э/м индукции еще может хватить запитать лампочку, но для элеткроники не хватит.

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