Введение

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

Поколения программистов

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

1. Поколение программистов математиков (1940-1960)

Как известно более старые книги по математике времён СССР лучше более поздних того же СССР и России. В некотором роде книги по математике деградировали так же, как и книги по программированию. Люди, до 60-ых годов получали гораздо более простые и насыщенные источники информации, просто потому, что у них не было выбора взять худшие варианты из будущего. Похожее случилось и с программированием.

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

Исходные диаграммы сущности-связи

ER-модель (от англ. Entity-Relationship model, модель «сущность — связь») — модель данных, позволяющая описывать концептуальные схемы предметной области.

Элементы диаграммы в Dia

В Dia элементы диаграммы выглядят так.

Простая схема сущности-связи

Составим простую схему сущности связи.
1. Без отношения множества. Один к одному. Один ко многим. Многие ко многим.
2. Без направления связей. Указаны стрелочками.
3. Без указания количества ссылок на одну и ту же сущность. Обычно число справа вверху над сущностью.

Сокращаем схему до сущностей

Далее вопрос, а так ли нужны.
1. Отношения.
2. Атрибуты.

В конечном счёте.
1.

Свободные (популярные)

Рекомендуется использовать.

1) Assembler (*.asm, *.s, *.inc, *.wla, *.src)
2) Bash (*.sh)
3) С (*.h, *.с)
4) C++ (*.hh, *.cc, *.hpp, *.cpp, *.hxx, *.cxx, *.h++, *.c++, *.h, *.с)
5) JavaScript (*.js, *.cjs, mjs)
6) Lua (*.lua)
7) Pascal (*.pas, *.inc, *.pp)
8) Php (*.php, *.phar, *.phtml, *.pht, *.phps)
9) Python (*.py, *.pyi, *.pyc, *.pyd, *.pyw, *.pyz)
10) Ruby (*.rb)
11) Structured text (*.st, *.stx)

Свободные (непопулярные)

Для расширения кругозора.

1) Ada (*.adb, *.ads)
2) Basic (*.bas)
3) D (*.d, *.dd, *.di, *.def)
4) Lisp (*.lisp)
5) Objective-C (*.h, *.m, *.mm, *.c)
6) Perl (*.pl, *.pm, *.plx, *.xs, *.t, *.pod, *.cgi)
7) Prolog (*.pl, *.pro, *.p)
8) Tcl (*.tcl, *.tbc)

Собственнические (проприетарные)

Не рекомендуется использовать.

1) C# .NET (*.cs, *.csx) владелец Microsoft
2) Dart (*.dart) владелец Google
3) Delphi (*.pas, *.dpr, *.dpk, *.pp, *.dproj, *.dfm, *.fmx, *.bpl) владелец Borland

Бесплатные кастрированные игры

Более трети игр, купленных в Steam, не запускались ни разу



А часть из тех, что запускались делали это через программу для фарма карточек. То есть вся эта фармилка ещё "двигает" индустрию продаж игр, но не индустрию игры в игры.

Здесь ещё нужно понимать, что такое бесплатно.

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

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

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

Опрос

Недавно я создал опрос с аналогичным названием. И немногочисленные проголосовавшие в основном пока за вариант с сайтом компании.

https://rsdn.org/poll/8900

Проблемы

Но давайте разберём преимущества и недостатки каждого варианта согласно порядку текущей популярности голосования.

1. Программный продукт на сайте компании.
2. Программный продукт на чужих сайтах.
3. Программный продукт на своём сайте.

Программный продукт на сайте компании

Какое-то время назад я сам был за этот вариант.

Преимущества.
1. Относительная экономия ведь платим за домен и хостинг лишь одного сайта.
2. Проще сменить название продукта, ведь для этого не нужно пересоздавать домен.
3. Лёгкость управления множеством продуктов и всегда можем сменить поддомен продукта на подпапку и наоборот.
4. Получаем единый бренд для всех программных продуктов, что позволяет продвигать программные продукты за счёт друг друга.

Недостатки.
1.

В чём разница?

На вопрос в чём разница между зачем и почему интернет мне выдаёт ответы людей.
1. Почему? = По какой причине?
2. Зачем? = С какой целью?

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

                      над верх
+-------+            +---по---+
|субъект| пред перед | объект | за зад
+-------+            |в внутри|
                     +--------+
                      под низ

Возьмём для примера утверждение, что "солнце жёлтое".
1. Почему солнце жёлтое?
2. Зачем солнце жёлтое?
3. Отчего солнце жёлтое?
4. С чего солнце жёлтое?

Лично я не вижу разницы между этими вопросами.

Но самое главное, если бы я хотел различать причину и цель, то так бы и сказал.
1. По какой причине солнце жёлтое?
2. С какой целью солнце жёлтое?

Смыслоуловители

Так понимаю ответы людей просто кого-то цитируют.

Ну что, осталась одна версия до выхода Rust 1.0! Ждем лета 2014
Если говорить о самых интересных изменениях в 0.9, то они довольно серьезные:

• Удалены managed boxes (@) и вместо них необходимо использовать `Gc` или `Rc` из стандартной библиотеки. Решение временное, скоро будет добавлены некий синтаксический сахар для того что бы сложность использования относительно @ не возрастала.
  
• Добавленна поддержка статических библиотек, В OSX поддерживаются фрэймворки.
  
• Начался крупномасштабный рефакторинг IO подсистемы, теперь есть две библиотеки libgreen и libnative, отличающиеся использованием libuv и нативных потоков.

Ну и еще много чего, в итоге разломано все сильно и нашу статью про Rust однозначно надо править При этом, следующий релиз будет последним ломающим изменения релизом:

[q]We plan on not breaking code after Rust 1.0, except for gated features. That said...

Теория и практика

Данная статья является продолжением заметки Словесный поток и чёткие структуры, в которой были рассмотрены теоретические предпосылки текстовой записи разных форматов. Теперь настало время перейти к практике от вопроса "зачем делать?" к "как делать?".

Способы конспектирования

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

Лента списков

Создание главы:
1) Создайте текстовое название главы книги или статьи.
2) В название главы можно добавить нумерацию без лишних символов окончания.

Причины для английского языка

Давайте спросим себя для чего в программировании пишем все названия на английском.

1. Для того чтобы код работал

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

1) Проект не скомпилируется из-за недопустимых символов в именовании файлов или папок.
2) Проект скомпилируется, но потом не откроется в какой-нибудь чисто англоязычной консоли, да хотя бы потому, что там нельзя будет набрать путь.
3) Проект не скомпилируется начав ругаться на идентификаторы в программе, такие как название переменных, функций, классов.
4) Строковые литералы могут не отобразиться в консоли даже в кодировке UTF-8.

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

2. Для того чтобы код понимали

А вот эта тему уже более интересна.

Предпосылки

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

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

Сидячий образ жизни

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

И это общеизвестный факт. Тот же Линус Торвальдс пытался скомпенсировать этот негативный эффект установив беговую дорожку. Вы легко можете найти статьи и видео в интернете на эту тему.