На русском — не видел. Но и искал не очень пристально.
Как ни странно, очень хорошим источником информации является штатная документация. Написано очень внятно, достаточно подробно. Что важно, практически всегда позволяет понять, зачем сделано так, а не иначе.
Если учесть, что издательства ориентирудются в основном на сценарий «как молодому студенту заработать себе на пиво», то ситуация вполне закономерна.
У меня нет ни одной русскоязычной книги по Java, в приобретении которой я бы не раскаивался. Начиная от книжки про JDBC, представляющей собой тупой подстрочник, до Core Java, которую переводил человек, вообще не знакомый с предметом.
Причем, последние 10 лет ситуация имеет тенденцию усугубляться.
К сожалению, J2EE-разработчики, которых мне приходилось собеседовать последние 5 лет, в массе откровенно паршиво знают именно «азы HTTP и приципы работы сессий». К примеру, в среднем 1 из 10 знает, что Get-запросы могут кэшироваться, а POST- — никогда. А уж критерии кэшируемости Get-запросов — это уж совсем как rocket science.
Молодому студенту на 1-2 курсе J2EE ни к чему. А к 3 курсу взрослый студент обязан знать язык на уровне, позволяющем с трудом, но читать техническую литературу по специальности.
Истинно так. Такие тесты имеют смысл только как средство первичного отбора — когда физически нет возможность пригласить на интервью сотни людей, приславших резюме. Ибо неэффективно тратить своре время на разговор с человеком, который после прочтения «Java за 24 часа» присылает резюме на Senior Java Developer. Для чего-то большего такие тесты бессмысленны.
Он, собственно, никогда экспертом и не был. :) Навыки social engineering у него есть, тем и живет, подробности в его книгах. Просто пока тупые журналисты переписывали друг у друга его историю, расцвечивая ее фантастическими подробностями, и постепенно возвели его в ранг эксперта.
Соответственно, особо одаренная хакерская мОлодеж, обчитавшись этих статей, пытается доказать свою крутость, как-то опустив Митника. Романтика типа. Случай уже не первый.
1. Контроллер уже есть, нужно будет лишь расширить его функции. Причем, в меньшей степени, чем для синхронизации. Но нужно осознавать, что такая флэшка будет стоить в 3-N раз дороже обыкновенной.
2. В технике не бывает механизмов со стопроцентным срабатыванием. Ну то есть совсем не бывает. Что касается фиксаторов, то те же самые RJ-разъемы китайского производства несмотря на фиксатор не гарантируют контакта. У самого в хозяйстве два таких долбанутых кабеля. А механическая часть USB-сокетов (всех типов) вполне корректна — при условии соблюдения допусков, разумеется. Если же сокеты штампует в гараже дядюшка Ло с племянниками на самодельном станке — ни о допусках, ни о качестве говорить не приходится. Повторюсь: конструкторскими мерами это не решить.
… что касается резервирования, то нет смысла делать отдельную флэшку в колпачке и заботиться о синхронизации. Достаточно поместить в корпусе 2 (или более — см. RAID) накопителя вместо одного. Синхронно пишем, при чтении контролируем повреждения. Соответственно, получаем требуемую надежность без геморроя для пользователя.
Это я все к тому же — к правильной постановке задачи. Пользователю не нужно дублирование данных и он не хочет думать о синхронизации. Ему нужно, чтобы данные не терялись. Как это сделать — давно уже не вопрос.
Спасибо, добрый человек. Видел я как-то раз фото российской оборонной флэшки с привинчивающимся разъемом, навскидку похожим на DB-25. Так что Вы здесь шутите — а люди это на полном серьезе воплощают за казенные деньги.
В статье допущена принципиальная ошибка: проблема не в конструкции USB-сокета, а в качестве производства. Бороться с низким качеством изыскиванием особой конструкции сокета — тупиковый путь.
К примеру, я вполне застал в девяностые китайские BNC-сокеты, которые либо просто не вставлялись, либо легко выпадали несмотря на наличие защелки.
Так что прежде, чем проблему решать, нужно ее правильно определить.
А смысл? Предположим, производительность работы в этом загородном «офисе» повысится на 50%. Суммарное повышение составить 10-15%. Ради этого вкладывать такие средства?
Многие уже сейчас готовы туда ехать, особенно программисты, которым, кроме интернета, ничего для работы больше не нужно
… и у которых кроме работы нет никакой жизни — ни жены, ни детей, ни желания сходить в клуб/театр. Которые готовы были бы и в офисе на матрасе жить (я пробовал, кстати).
Спасибо, Вы привели хороший пример ложной уверенности. Практически все промышленные СУБД предоставляют средства доступа к метаданным. Соответственно, при наличии sql injection нет ничего катастрофически сложного в том, чтобы получить доступ к таблице, зная не ее полное имя, а только уникальный постфикс. Сложность и осуществимость зависят, разумеется, от характера sql injection.
У примеру, в MySQL можно начать с протаскивания примерно такого запроса:
select * from information_schema.tables where table_name like '%users'
Соответственно, человек, сменив префикс на уникальный, ощущает ложную безопасность и не будет так спешить ставить фикс.
Как ни странно, очень хорошим источником информации является штатная документация. Написано очень внятно, достаточно подробно. Что важно, практически всегда позволяет понять, зачем сделано так, а не иначе.
— Коллега, Вы просто не умеете их готовить. :)
У меня нет ни одной русскоязычной книги по Java, в приобретении которой я бы не раскаивался. Начиная от книжки про JDBC, представляющей собой тупой подстрочник, до Core Java, которую переводил человек, вообще не знакомый с предметом.
Причем, последние 10 лет ситуация имеет тенденцию усугубляться.
Соответственно, особо одаренная хакерская мОлодеж, обчитавшись этих статей, пытается доказать свою крутость, как-то опустив Митника. Романтика типа. Случай уже не первый.
2. В технике не бывает механизмов со стопроцентным срабатыванием. Ну то есть совсем не бывает. Что касается фиксаторов, то те же самые RJ-разъемы китайского производства несмотря на фиксатор не гарантируют контакта. У самого в хозяйстве два таких долбанутых кабеля. А механическая часть USB-сокетов (всех типов) вполне корректна — при условии соблюдения допусков, разумеется. Если же сокеты штампует в гараже дядюшка Ло с племянниками на самодельном станке — ни о допусках, ни о качестве говорить не приходится. Повторюсь: конструкторскими мерами это не решить.
Это я все к тому же — к правильной постановке задачи. Пользователю не нужно дублирование данных и он не хочет думать о синхронизации. Ему нужно, чтобы данные не терялись. Как это сделать — давно уже не вопрос.
К примеру, я вполне застал в девяностые китайские BNC-сокеты, которые либо просто не вставлялись, либо легко выпадали несмотря на наличие защелки.
Так что прежде, чем проблему решать, нужно ее правильно определить.
Да и концепция позависать в клубе с бомондом города Донского не у всех родителей вызовет бурный энтузиазм.
… и у которых кроме работы нет никакой жизни — ни жены, ни детей, ни желания сходить в клуб/театр. Которые готовы были бы и в офисе на матрасе жить (я пробовал, кстати).
Для таких — почему бы и нет. Хорошая идея.
У примеру, в MySQL можно начать с протаскивания примерно такого запроса:
Соответственно, человек, сменив префикс на уникальный, ощущает ложную безопасность и не будет так спешить ставить фикс.
Спасибо за пример.