Category: it

Category was added automatically. Read all entries about "it".

цветная

Мой комментарий к «Foundational ontologies -- типы в языках программирования против БД (2/2)» от…

Реляционное в базе и разложенное по объектам в памяти — естественное и вынужденное следствие возможности произвольного доступа к оперативке и более естественного изрядно последовательного доступа к дорожке диска. И, ИМХО, практически ничего сверх этой разницы.

Посмотреть обсуждение, содержащее этот комментарий

цветная

Михаил Донской: Жизненный цикл программиста - ПОЛИТ.РУ

Михаил Донской: Жизненный цикл программиста - ПОЛИТ.РУ

Статья известного российского системного программиста, зав. лабораторией Института системного анализа РАН, члена Российской академии интернета, автора шахматной программы «КАИССА» (первого чемпиона мира среди шахматных программ), президента компьютерной фирмы ДИСКо, лауреата вс…

Posted by Илья Ненашев on 2 дек 2015, 17:35

from Facebook
цветная

Джеймс Хэг. Что ещё оптимизировать, кроме скорости и памяти

Оригинал взят у mercury13_kiev в Джеймс Хэг. Что ещё оптимизировать, кроме скорости и памяти


Оригинал: Things to Optimize Besides Speed and Memory


Интересно (хоть и нечасто нужно) оттачивать функцию, чтобы она давала тот же результат, но меньшим количеством операций. Это такое же упражнение для мозгов, как кроссворды и судоку. Да, незачем оптимизировать процедуру на C++, если скорости хватает и на интерпретируемом Питоне. Но для «оптимизаторского рефлекса» найдутся и другие цели, и стоит переучиться, чтобы отдавать им больше внимания.


Потребление энергии, время работы от аккумулятора, нагрев и шум вентилятора.


Количество операций записи на диск (особенно для твердотельных накопителей). Вы случайно не перезаписываете неизменившиеся файлы?


Размер и сложность документации.


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


Количество байтов сетевого трафика. В сетевых играх этим занимались с самого начала, но сейчас почти во всех программах есть сеть, и иногда в эту сеть ходят по дорогим телефонным сетям или медленному общедоступному Wi-Fi.


Размер файла #include. Это связано больше с количеством объектов, доступных для программиста, чем с объёмом в байтах.


Количество нажатий, которые нужно сделать, чтобы выполнить задачу.


Время запуска программы.


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


Количество исключений из правил, которые нужно продокументировать: и в инструкции, и в коде.


Длина статьи в блоге.

цветная

Роберт Гласс. Факты и заблуждения о разработке ПО

Оригинал взят у mercury13_kiev в Роберт Гласс. Факты и заблуждения о разработке ПО


Этот пост — реферат книги R. Glass. Facts and Fallacies of Software Engineering.


ФАКТ 1. Производительность программиста больше зависит от его личности, чем от инструментария и используемого языка. Нет, программист — не заменяемый винтик.


ФАКТ 2. Профессионал высшего класса в 28 раз производительнее начинающего. Поскольку оплата труда редко соразмерна, хороший программист — замечательное приобретение.


ФАКТ 3 (закон Брукса). Не добавляйте людей к запаздывающему проекту: он будет запаздывать ещё больше. Программист должен много освоить, прежде чем начать производительную работу.


ФАКТ 4. Производительность программиста сильно зависит от условий работы. (Личный опыт: на производительность влияет даже то, что я ем; наиболее удачная закуска — хороший хлеб.)


ФАКТ 5. Не поддавайтесь на шумиху: большинство инструментов добавляют к производительности программиста от 5 до 35%. Но точно не в разы, как уверяет реклама. Эра «серебряных пуль» — 50-е годы — давно прошла.


ФАКТ 6. Во время освоения любого инструмента программист теряет в производительности. Так что стоит переходить на новый инструмент, только если его ценность не преувеличена. И, конечно, дайте программисту освоиться.


ФАКТ 7. Программисты много говорят об инструментах. Они пробуют изрядную кучу, кое-что покупают, а используют лишь малую долю.


ФАКТ 8. Одна из двух причин упущенного срока — неверная оценка сроков.


ФАКТ 9. Большинство оценок делается не тогда, когда надо: ещё до начала разработки, до того, как проблема понята и разобрана.


ФАКТ 10. Часто оценки навязываются не теми, кто собственно программирует, а высшим начальством.


ФАКТ 11. Оценки редко передвигаются, когда начинают собственно разрабатывать.


ФАКТ 12. С такими оценками не стоит и заботиться, чтобы вписаться в срок. Но всё-таки программисты ужимают себя.


ФАКТ 13. Зачастую начальство не имеет связи с программистами. Один проект, который начальство назвало «полным провалом», разработчики посчитали «самым удачным проектом, в котором мы участвовали».


ФАКТ 14. На вопрос «можно ли это сделать» ответ почти всегда «да».


ФАКТ 15. Повторное использование кода «по-малому» (в виде внутренних библиотек) — хорошо исследованная задача: ей пятьдесят лет!


ФАКТ 16. Повторное использование кода «по-крупному» (в виде компонентов) — всё ещё нерешённая проблема, хоть и все считают, что это важно и желательно.


ФАКТ 17. Компонентное программирование лучше всего работает для ряда связанных задач. Это сужает применимость подхода.


ФАКТ 18. Есть два «правила трёх». Компонент, пригодный для повторного использования, сделать втрое сложнее, чем одноразовый. И, чтобы он показал свою ценность, его надо испробовать на трёх разных проектах.


ФАКТ 19. Переделки повторно используемого кода ведут к ошибкам. Если более 20 или 25% компонента надо переделать, проще написать новый с нуля.


ФАКТ 20. Шаблоны проектирования — решение одной из проблем повторного использования кода.


ФАКТ 21. Когда сложность задачи повышается на 20%, сложность её кода поднимается на 100%.


ФАКТ 22. 80% работы программиста — интеллектуальная. Большинство этой работы творческая, и лишь небольшая часть — конторская.


ФАКТ 23. Вторая причина запоздалого проекта — меняющееся ТЗ.


ФАКТ 24. Ошибки в ТЗ надо исправлять как можно раньше: чем позже вы их заметили, тем они дороже.


ФАКТ 25. Самые сложные из ошибок ТЗ — упущенные требования.


ФАКТ 26. При переходе от ТЗ к архитектуре получается «архитектурный взрыв». Архитектурных компонентов будет в 50 раз больше, чем пунктов ТЗ.


ФАКТ 27. Редко бывает единственно правильное архитектурное решение для программной задачи.


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


ФАКТ 29. Программисты переходят от проектирования к написанию, когда задача будет разбита на такие примитивы, которые проектировщик точно осознаёт. Если проектировщик и программист — разные люди, ви́дение проектировщика точно не совпадёт с ви́дением программиста, и будет конфликт.


ФАКТ 30. КОБОЛ — плохой язык, но остальные (для обработки данных предметной области) ещё хуже.


ФАКТ 31. Больше всего времени займёт отладка.


ФАКТ 32. Программа, которая кажется хорошо проверенной, покрыта на 55–60% путей. С автоматическими инструментами, вроде анализатора покрытия, цифру можно поднять до 85–90%. Но до 100 — никогда.


ФАКТ 33. Даже если бы 100-процентное покрытие было возможно, ошибки всё равно будут. 35% будет от пропущенных путей исполнения, и ещё 40% от необычной комбинации двух путей. Программа будет покрыта на 100%, и эти ошибки не будут найдены.


ФАКТ 34. Практически невозможно избавиться от ошибок без инструментария. Обычно используют отладчики, а вот анализаторы покрытия — никогда.


ФАКТ 35. Не всё тестирование автоматизируется. Даже в автоматическом тестировании есть много ручной работы.


ФАКТ 36. Отладочный вывод и самопроверки, включающиеся по условной компиляции, хорошо дополняют средства тестирования.


ФАКТ 37. Хорошая ревизия может убрать до 90% проблем ещё до того, как будет запущен первый тест.


ФАКТ 38. Но тестирования ревизия не заменит.


ФАКТ 39. Ретроспективная (после сдачи) ревизия важна: она помогает найти слабые места проекта.


ФАКТ 40. Ревизия — и техническое дело, и социологическое. И одно без другого немыслимо.


ФАКТ 41. Сопровождение занимает от 40 до 80% расходов.


ФАКТ 42. 60% из расходов на сопровождение — расширение. 17% — исправления.


ФАКТ 43. Сопровождение — не задача, а решение. Делать изменения в программе — дело нетривиальное, но другие решения ещё сложнее.


ФАКТ 44. 30% расходов на сопровождение — «понять, как оно работает».


ФАКТ 45. Хорошая архитектура — это больше сопровождения. А не меньше. Это прямое следствие факта 43.


ФАКТ 46. Качество — это куча противоречивых параметров: портабельность, тестируемость, производительность, понятность/модифицируемость, эргономика, надёжность. Для среднего проекта приоритет именно таков, от маловажных к критичным.


ФАКТ 47. Качество — это ни удовлетворение пользователя, ни выполнение ТЗ, ни время и бюджет, ни надёжность.


ФАКТ 48. Есть ошибки, которые случаются сплошь и рядом. Даже если программист знает, что такие есть.


ФАКТ 49. Ошибка не приходит одна: часто есть несколько связанных.


ФАКТ 50. Нет единственно правильного подхода по изничтожению ошибок.


ФАКТ 51. Ошибки всегда будут. Наша цель — перекрыть путь самым серьёзным из них.


ФАКТ 52. Производительность идёт не от хорошего программирования, а от хорошего проектирования.


ФАКТ 53. Язык высокого уровня даёт до 90% от производительности ассемблера. А на некоторых «особо сложных» архитектурах проигрывает даже ассемблер.


ФАКТ 54. Как правило, выиграешь по скорости — проиграешь по памяти. Приходится выбирать, что важнее.


ФАКТ 55. Многие исследователи — на самом деле пропагандисты. В результате пропагандируемые концепции не так круты, как считают их сторонники; а надёжных исследований по этому поводу мало.


ЗАБЛУЖДЕНИЕ 1. Нельзя управлять тем, что нельзя измерить.


ЗАБЛУЖДЕНИЕ 2. Управленец может сделать продукт качественнее.


ЗАБЛУЖДЕНИЕ 3. Программирование должно быть — и может быть — без перехода на личности программистов.


ЗАБЛУЖДЕНИЕ 4. Если инструмент подошёл там, то подойдёт и тут.


ЗАБЛУЖДЕНИЕ 5. Нужно больше методик разработки.


ЗАБЛУЖДЕНИЕ 6. Чтобы оценить сроки, надо оценить количество строк.


ЗАБЛУЖДЕНИЕ 7. Случайные «краш-тесты» помогут оптимизировать тестирование.


ЗАБЛУЖДЕНИЕ 8 (закон Линуса). Когда много глаз, ошибки выплывают на поверхность. (От меня: буквально недавно проскочила ошибка OpenSSL Heartbleed).


ЗАБЛУЖДЕНИЕ 9. Затраты на сопровождение можно оценить по прошлым затратам.


ЗАБЛУЖДЕНИЕ 10. Когда учат программированию, учат, как писать программы.

цветная

Роскомнадзор разъяснил, что считать гей-пропагандой | Lesbiru.Com

Роскомнадзор разъяснил, что считать гей-пропагандой | Lesbiru.Com

Хороших геев быть не может: Роскомнадзор опубликовал на официальном сайте информацию, что считать гей-пропагандой и прочей «вредной для развития детей» информацией. Текст разъяснений, относящийся к «гей-пропаганде», еле уместился на 79 страницах (документ 109 стр.) Все остальные документы «Концепции...

Posted by Илья Ненашев on 14 апр 2014, 05:15

from Facebook
цветная

Томография

Обнаружил я, что существует в природе интересная штука - дентальный томограф Sirona Galileos. Он делает 200 снимков за 14 секунд, и по ним создаёт томограмму - сферу, вписанную в куб размером 15³см³ и разрешением 0.3мм на воксель, то есть 512³ вокселей с 12 битной палитрой. В Москве, кстати, таких уже несколько.


Например, есть фирмочка, целиком живущая лишь для эксплуатации такого аппарата - www.cdct.ru. Вот в неё я сегодня и заглянул, чтоб купить за 5 тысяч рублей диск с массивом вокселей в формате DICOM, представляющим собой мою челюсть и все носовые пазухи, и программой-смотрелкой для него.


Ибо очень я интересуюсь как анатомией (и своей и вообще), так и компьютерной графикой (в частности, воксельной), и как узнал про это - очень загорелся.


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


Что касается формата хранения: оказалось, что в папке с данными лежат отдельными файликами слои, запакованные gzip-ом (спасибо архиватору 7z, что подсказал), и представляющие собой простые массивы 512*512 парных байт, в которых хранится рентгено-прозрачность каждого вокселя, на что занято по полтора байта из этих двух. В распакованном виде этот воксельный куб занимает 256 мегабайт, что вполне укладывается в оперативку. Что я и сделал, задействовав модули библиотеки TurboPower Abbrevia, которые на чистом и красивом дельфовом паскале предлагают распаковывать и запаковывать почти всё что угодно! (а TurboPower, оказывается, ещё много вкусного сделал и открыл!) Спасибо им, и какому-то форуму, в котором их когда-то кому-то советовали.


Кроме того, в файлах с данными лежит две xml-ки, одна не запакованная, а другая - запакованная. Обе соджержат какую-то информацию про томограмму, а запакованная кроме того содержит ФИО пациента и ещё что-то про место и время сканирования. Но это мне уже не так интересно.
цветная

GIT, HG и прочие DVCS vs VSS, SVN и прочих SVCS

Кажись, я просёк то, что нигде никто явно не пытается писать — а мне без этого как-то непонятно было. У меня довольно большой опыт работы в VSS и некий опыт присматривания к SVN. А сейчас вот и к GIT-ам всяким присматриваюсь.

На страничке http://mercurial.selenic.com/wiki/UnderstandingMercurial в конце сказано, что если вы думаете держать в одном репозитории HG несколько родственных проектов, как привыкли в системах типа SVN, то лучше одумайтесь, ибо HG на это не рассчитан. Похоже это потому, что он всегда работает со всей рабочей папкой в целом.

Это хороший пример следствия из того, о чём я хочу сказать: у этих новомодных распределённых систем понятие дерево каталогов и файлов в рабочей папке ортогонально дереву её версий. Это есть второе (после наличия локального репозитория) ключевое отличие этих систем от предыдущих.

В SVN и VSS — различные версии одной и той же рабочей папки предлагалось оформлять соседними папками в других папках репозитория, и соответственно дерево папок репозитория содержало не одну рабочую папку, а целый их набор, лежащих в различных подпапках в отдельно специально сфабрикованной корневой папки репозитория и ряда её служебных подпапок типа branch и trunk. Это приводило систему к необходимости давать пользователю возможность работать то с одной отдельной подпапкой репозитория, то с другой, и копировать одну в другую с сохранением истории, сливать соседние папки одну с другой, и т.п. И, в следствие такого умения, эти системы давали возможность в других подпапках того же репозитория хранить версии рабочих папок других, родственных, проектов. И соответственно, права на разные папки разным людям давать разные. Кому одни вовсе не видеть, кому другие не редактировать.

А GIT и HG отделили понятия дерева версий и дерева папок, и поэтому изначально не имели нужды поддерживать работу с подпапками, и всегда работают в рабочей папке с репозиторием в целом, и ветвят её варианты уже исключительно в рамках её истории. Одновременно на диске увидеть две версии папки из одного такого репозитория невозможно — только если рабочую папку в состоянии одной версии куда-нибудь скопировать, и потом переключить рабочую папку на отображение другой версии (= забрать в неё из локального репозитория другую версию). И права доступа — лишь на репозиторий в целом, либо писать процедурные хаки, которые будут отвергать часть присылаемых из другого репозитория правок, не устраивающих хозяина этого репозитория. Сейчас вот думают как бы наверстать — HG делает subrepos, например...
цветная

Стартап про удобное хранилище связанных заметок...

Писал много текста в темку про новый стартап, ищущий генератора идей. Стартап про удобное хранилище связанных заметок. Меня понесло, и я накидал туда многа букф. Интересно, осилят?

Collapse )
цветная

Чтоб программировать, надо...

Чтоб программировать, надо...

...знать:

Любому программисту

  • знать язык, то есть его синтаксис
  • знать библиотеки. Библиотеки, в общем смысле - это:
    • сама среда выполнения программы (Операционная система)
    • всевозможные обёртки для доступа к возможностям среды и общих библиотек
    • прикладные библиотеки, самостоятельно реализующие какой-либо функционал
  • знать среду разработки
    • уметь пользоваться редактором (интегрированными и отдельными редакторами кода, окон, компонентов, проектов, изображений и т.п.)
    • уметь пользоваться отладчиком - трассировать и, по мере трассировки, отслеживать нужные аспекты выполнения программы

Программисту, работающему в коллективе, надо ещё знать и про средства коллективной работы

  • средства управления версиями исходников
  • средства управления требованиями
  • средства управления планами

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

  • средства документирования
  • средства разворачивания (установки) и оплаты
  • средства сопровождения (обмена информацией со службой поддержки)

Примечание

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

...понимать, что:

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