Блокировки блокировкам рознь. Полная защита работает только при максимальном уровне изоляции — SERIALIZABLE. Т.е. я вроде не противопоставляю блокировки и транзакцию, а говорю о том, что просто транзакции не достаточно. Вообще, исходная задача транзакции несколько иная — обеспечить возможность отката пачки изменений. А не синхронизация. Но по факту функционал транзакций позволяет использовать их для сихронизации при соблюдении условий и выбора соответствующего уровня изоляции.
Кстати, в задаче со счетчиком достаточно уровня изоляции repeatable read.
Не достаточно. Очень легко запустить приведенный по ссылкам выше код на любой машине, где есть PHP и MySQL. А после просто удалить файл и выполнить блок очистки, чтобы мусора не осталось. Попробуйте запустить его с уровнем REPEATABLE READ.
Нет, не тривиально. Несколько запросов параллельно могу сравнить и получить разрешение на закачку. И, соответственно, закачать. Решение здесь есть через UPDATE… fact=fact+1… WHERE id = x AND limit < fact, а потом посмотреть affected rows — если оно больше нуля, то принять закачку. Но это не тривиальное решение. И я не думаю, что все повально им пользуются.
Причем, это вообще будет работать только если есть fact. А если нет, то нужно вести подсчет на лету, и это уже не прокатит.
Вот интересно. Большая часть участников опроса полагается на транзации. Гораздо меньше людей используют блокировки. 55 % сообщают, что вопрос блокировок у них не стоит вообще. Но при решении проблемы с файлом, которая приведена в примере (т.е. проблема счетчика-ограничителя в общем случае), транзакция поможет только при уровне SERIALIZABLE. А это убивает производительность. Кроме того, по умолчанию в MySQL стоит REPEATABLE READ. Не думаю, что все повально его меняют на SERIALIZABLE. А это очень распространенная задача.
А это значит для примере со счетчиком, что либо нужно использовать блокировку, либо будет дырка при одновременном выполнении. Скорее всего на это просто закрываются глаза.
Воспроизвести пример и поэксперементировать с ним можно с помощью этого: test.php test.sql
Это очень странно, учитывая, что 40 % опрошенных отметили, что разбираются в теме.
Знать можно по-разному. Если обзорные знания по всем областям реально можно получить (а нужно ли сразу по всем — имхо индивидуально), то глубокие знания по всем ним получить уже просто физически не реально, и не нужно. Получить обзорные знания по любой дисциплине на схеме можно прочитав одну хорошую книгу. Причем, общую базу все изучают в школе, а из того, что выше большую часть — на всех более-менее программерских специальностях в ВУЗах.
Наверное, криптографию нужно было всадить на 1-м уровне с опорой на обработку информации. Могу ошибаться, но мне кажется, что вне экспертного уровня это небольшая область знаний. А вот самая соль и криптографии, и безопасности как аспекта во всех других областях знаний, должна проявляться на экспертном уровне, который я вообще не раскрывал, обозначив лишь 3 примера.
Владеть математикой должен математик. Электротехникой — электротехник. Программисту достаточно обзорных знаний в областях, далеких от непосредственно применяемых в работе. И уж тем более речи нет о том, что программист должен знать все, перечисленное на схеме (плюс еще то, что я упустил :)). Но все же чем больше знать будет, тем будет для него лучше, это уж точно. Не сейчас, так через 10–20 лет, когда нужно будет конкурировать с молодыми.
ИМХО: годы опыта заменяют месяцы обучения. Я это и на своей шкуре прочувствовал, и по коллегам вижу. По моим прикидкам, если бы я пошел по схеме снизу вверх в универские годы (а не сверху вниз, как вышло на практике), то сэкономил бы несколько лет опыта, которые ушли на получение знаний через практику.
Да, потому что в этой классификации «веб-технологии» — это более узкое понятие, чем обычно имеется в виду:
веб-технологии (HTTP-протокол, веб-сервер, CGI, кэширование и проксирование, клиентское программирование);
Дело в том, веб — это не только сайты, где БД действительно используются в большинстве случаев. Но даже на сайтах далеко не на всех есть БД. Сайт может быть статическим, либо в роли хранилища может быть не БД, а, например, файловая система или Amazon S3. Сами по себе технологии, на которых строится Интернет, не опираются на базы данных.
Но, когда мы говорим о программистах, которые делают сайты, то в подавляющем большинстве случаев требуется знание баз данных. Просто идет оно отдельным пунктом, а не в составе знания с веб-технологий.
3. Жаль, что не увидел в этой схеме место кибернетики (науки об управлении), за то управлению командами разработки, по сути менеджементу (лженауке об управлении) место нашлось.
Я не силен в кибернетике и скорее всего ее отсутствие — упущение. А вот что касается управления командами и проектами, т.е. элемента менеджмента, я не согласен. Во-первых, это реально нужно в практике тем, кто собирается стать даже на самую нижнюю ступень руководства. Во-вторых, программисты работают в проектах по какой-то системе. Если взята готовая модель, программисты должны понимать, как она работает, даже будучи ее объектом. Ну а если модель формируется в команде эмперически, то тем более лучше иметь какие-то знания в этой области, чтобы сделать лучше.
Чтобы целиком одним махом закрыть сети, ОС и железо, я могу порекомендовать:
Архитектура компьютера, Таненбаум
Компьютерные сети, Таненбаум
Современные операционные системы, Таненбаум
А по программированию классику. Чистый код (или Совершенный код — дело вкуса), Рефакторинг, что-то по паттернам, Программист-прагматик, книги Джоэла Спольски. Ну и, конечно, книги по своим языкам и технологиям.
На сколько такое решение подходит для организации облака на серверах без выделенного хранилища? Т.е. есть несколько мощных серверов с дисками в каждом. Нужно запустить на них облако, причем желательно, чтобы ни один сервер не вышел из полностью эксплуатации (т.е. не выделился под нужды самой системы облака).
OpenStack как ни крути сложная штука. Чтобы ее использовать, нужно хорошо в ней разобраться. Это все понятно. Но вот где бы найти хороший и современный обзор ее возможностей, чтобы начинать с общей картины, а не подробностей.
Ну да, надо немного сменить образ работы. Он отличается. Но тут фишка в том, что Evernote (или другая утилита такого плана) — это полноценное хранилище информации, а заметки в Опере — свалка. Переходите на новый уровень. Мучаться придется недолго, потом привыкните и будет профит :)
Мне заметки в свое время заменил Evernote, чем я сейчас очень доволен, ибо им пользоваться оказалось удобнее :) Но как основной браузер для серфинга на работе у меня по прежнему 12-я Опера (не из-за заметок, конечно).
Блокировки блокировкам рознь. Полная защита работает только при максимальном уровне изоляции — SERIALIZABLE. Т.е. я вроде не противопоставляю блокировки и транзакцию, а говорю о том, что просто транзакции не достаточно. Вообще, исходная задача транзакции несколько иная — обеспечить возможность отката пачки изменений. А не синхронизация. Но по факту функционал транзакций позволяет использовать их для сихронизации при соблюдении условий и выбора соответствующего уровня изоляции.
Не достаточно. Очень легко запустить приведенный по ссылкам выше код на любой машине, где есть PHP и MySQL. А после просто удалить файл и выполнить блок очистки, чтобы мусора не осталось. Попробуйте запустить его с уровнем REPEATABLE READ.
Причем, это вообще будет работать только если есть fact. А если нет, то нужно вести подсчет на лету, и это уже не прокатит.
А это значит для примере со счетчиком, что либо нужно использовать блокировку, либо будет дырка при одновременном выполнении. Скорее всего на это просто закрываются глаза.
Воспроизвести пример и поэксперементировать с ним можно с помощью этого:
test.php
test.sql
Это очень странно, учитывая, что 40 % опрошенных отметили, что разбираются в теме.
Как задача счетчика-ограничителя решается у вас?
Дело в том, веб — это не только сайты, где БД действительно используются в большинстве случаев. Но даже на сайтах далеко не на всех есть БД. Сайт может быть статическим, либо в роли хранилища может быть не БД, а, например, файловая система или Amazon S3. Сами по себе технологии, на которых строится Интернет, не опираются на базы данных.
Но, когда мы говорим о программистах, которые делают сайты, то в подавляющем большинстве случаев требуется знание баз данных. Просто идет оно отдельным пунктом, а не в составе знания с веб-технологий.
Я не силен в кибернетике и скорее всего ее отсутствие — упущение. А вот что касается управления командами и проектами, т.е. элемента менеджмента, я не согласен. Во-первых, это реально нужно в практике тем, кто собирается стать даже на самую нижнюю ступень руководства. Во-вторых, программисты работают в проектах по какой-то системе. Если взята готовая модель, программисты должны понимать, как она работает, даже будучи ее объектом. Ну а если модель формируется в команде эмперически, то тем более лучше иметь какие-то знания в этой области, чтобы сделать лучше.
А по программированию классику. Чистый код (или Совершенный код — дело вкуса), Рефакторинг, что-то по паттернам, Программист-прагматик, книги Джоэла Спольски. Ну и, конечно, книги по своим языкам и технологиям.
OpenStack как ни крути сложная штука. Чтобы ее использовать, нужно хорошо в ней разобраться. Это все понятно. Но вот где бы найти хороший и современный обзор ее возможностей, чтобы начинать с общей картины, а не подробностей.