Merzley: Каково сопротивление осцилографа? Емкость, необходимая для сглаживания до приемлемого уровня, зависит от сопротивления нагрузки. Чем оно меньше, тем бОльшая емкость нужна, чтоб напряжение оставалось "постоянным".
ColdSpirit: Точно также может статься, что излишние шероховатости на кузове и двигателе оскорбляют эстетическое чуйство человека, и он просто напросто хочет улучшить внешний вид этой краденной машины, а вовсе не то, что все подумали :)
Про ассоциацию и т.д. рассказывается популярно, а вот про UML - хреновенько. Если сначала не ткнуть носом в таксономию диаграм, то можно до посинения говорить про "диаграммы статической структуры", но читателю так и не станет понятно, что это такое и зачем, т.к. ему просто невдомек, а какие же еще бывают. Всего одна картинка, но если не начать с нее, то как-раз и получится вынос мозга :)
kaiiycta: Я не знаю, что советовать конкретнее, т.к. не знаю, в чем цель курсовой, какой ее объем и какой объем знаний уже есть, или предолагается получить в рамках этой работы.
Если цель (довольно странная) - познакомиться именно с десктопной БД, то "меняйте" на те, что я указал... скорее всего, на MS Access. Там "в одном флаконе" есть, собственно, реляционная БД с SQL, средства создания формуляров, генератор отчетов и VBA (Visual Basic for Application), на котором программируется логика приложения.
Если цель - познакомиться вообще с реляционными БД, то лучше взять (если под Винду), например, MS SQL Express + к нему понадобится Visual Studio Community. Сервер- это сервер, а в Visual Studio можно программировать формы и отчеты (на том же Visual Basic или, лучше, на C#). А если под Линукс, то можно, например, взять PostgreSQL (в качестве сервера) и, скажем, программировать веб приложение на том же PHP (понадобится еще HTTP-сервер, NGINX или Apache) или же десктопную апликацию, например, на Java. В качестве IDE берите JetBrain IDEA или Eclipse.
Возможны, разумеется, любые комбинации этих и еще дюжины других вещей, на которых можно "разработать ИПК". Абсолютно все - или OpenSource, или есть легально и бесплатно.
Если начальных знаний ноль, то варианты кроме первого, конечно, подразумевают ощутимо больше мороки, т.к. разбираться придется не только с БД и ЯП, но и с инструментами и их настройками. Но что бы не взяли, разницы с т.з. "полезности" знаний - никакой. В любом случае придется разобраться БД и SQL, и с каким-нибудь ЯП, и все это, в любом случае, наверняка пригодится в будущем.
А поприличее фото нет? По этому можно только с уверенностью сказать, что это НЕ Ардуина. Платы справа - это шилды (какие именно - сказать трудно). Да и основная плата, к тоторой они прикреплены, может быть не самой avaluation board (с контроллером), а т.н. break out / extension board.
Короче, с такими фото, надежда только на кого-то, кто узнает конкретно эту плату.
Urukhayy: Прежде всего, не нужно отождествлять бит (количество информации) с электрическим потенциалом, например, фронтом импульса, распространяюшегося в проводнике. Это разные вещи. Импульс - это вагон, а бит - это один пассажир в вагоне. Но в вагоне может быть и больше пассажиров... может быть пол-пассажира (один бит информации "едет" в двух разных вагонах)... а может и вообще не быть: вагон едет, но в нем пусто! Это в канале связи называется несущей (carrier), т.е. импульсами/колебаниями, не промодулированными никакой информацией.
Как в вагоне может одновременно поместиться больше одного пассажира? Да очень просто! За это отвечает протокол, т.е. изначальная договоренность сторон о том, какой смысл придается тому или иному вагону.
Сам по себе импульс, точно так же, как и бит, никакого смысла не имеет - смысл возникает, когда импульс приходит или не приходит, причем, в простейшем случае, не только из этого импульса, но также из пришедших или не пришедших ранее. Это вариант протокола с логической компрессией данных. Так, упрощенно говоря, один бит передаваемого черно-белого растрового изображения может означать один единственный черный пиксель на картинке, а может - если последовательность бит закодирована, например, RLE(run-length encoding) - целую область черного цвета. Бит пришел один, но с т.з. принимающей стороны, как только он "пришел", на экране отобразилась целая область из многих пикселей. Сколько он "принес" информации? Правильно, много!
Именно по этому в протоколах принято говорить не об отдельных передаваемых битах/импульсах и т.д., а об их цепочках, называемых пакетами. Развивая аналогию, пакет - это состав вагонов. Пакеты бывают разной длины и определяются протоколами разных уровней, а на первом уровне (на уровне физического носителя в виде медного провода) они кодируются импульсами, причем, совсем не обязательно, один бит - одним импульсом!
Но это все, так сказать, ИТ-шная верхушка айсберга :) Еще по крайней мере столько же, если не больше вариантов уплотнения информации существует на самом физическом уровне передачи информации по проводу с помощью электромагнитных колебаний. В ISO/OSI модели они называются обобщенно протоколами первого уровня. В основном речь идет о разных видах модуляции, уровнях, несущих частотах и т.д. Никого же не смущает тот факт, что каждая точка антенны радиоприемника в определенный момент времени имеет один потенциал, а разных радиостанций в этот момент можно слушать много? В проводе происходит все то же самое! По одному проводу можно передавать одновременно сигнал множества совершенно разных логических каналов.
Про один единственный импульс, распространяющийся в проводе, нельзя сказать, сколько он несет бит информации, если не знать при этом ВСЕХ протоколов (как "логических", так и "физических"), поучавствовавших в том, что вот он тут сейчас есть и распространяется :) А их очень много (целый стек!) и все они, в принципе, направлены на максимальное уплотнение передаваемой информации.
Павел: В самолетах эта конкретная магия только в начинке, а про ту, на которой они летают, я не могу рассказывать на Тостере. Иначе меня забанят за несоответствие тематике ресурса :) Но по сути Вы абсолютно правы - обе магии похожи друг на друга, как два листа одного дерева.
"Как правильно генерировать ключи для HashMap и какого типа?"
Где Вы там видите хоть слово про БД, внешний сервис или что-то похожее? В контексте БД или даже ORM вопрос просто не может возникнуть (если, конечно не заниматься костылестроением), т.к. за его решение там отвечает sequence / автоинкремент / композитный ключ / соотв. аннотация JPA... это все - вещи, никак не связанные с HashMap, а полностью вытекающие из логики задачи.
Если не начинать фантазировать, то вопрос из области банального знания (точнее, незнания) явовского collection framework, и касается конкретно ключей в Map. Вот и вся нехитрая философская доктрина :)
P.S. "Дополнительный" в данном случае просто синоним "сгенерированный", и означает, что какие-то данные создаются программой искусственно, а не вытекают из логики задачи / алгоритма / не вводятся в программу извне. Ваши аргументы были бы абсолютно справедливы в контексте БД, но, как я уже указал, этим в вопросе даже не пахнет.
Solver: Это, безусловно, любопытная и весьма творческая интерпретация вопроса... только, если ключи все-таки по логике задачи есть, то может возникнуть вопрос, который выбрать (Long, String и т.д.), а не как сгенерировать дополнительный. Опять же, возникнуть он может у тех, кому лень сделать лишний клик и заглянуть в имплементацию HashMap.
Только вот этого всего (вероятно, благодаря дислексии) я в вопросе не нашел, а нашел искуственные целочисленные ключи, которые, видимо, полностью удовлетворяют логике задачи. В этом месте остается только недоумевать, почему тогда не использовать массив и не получать объекты по... та-дам: тому же самому целочисленному индексу :) Это - принципиально быстрее и экономнее по памяти, чем любые хеши-меши. Более того, если ключ искуственный (сгенерированный), напрашивается следующий и, собственно, основной вопрос философии: а на кой он вообще нужен?! Если он сохраняется в каком-то отдельном от коллекции месте, почему не сохранить там... та-дам: поинтер на объект? Ну и, наконец, если, не взирая на здравый смысл, все же очень хочется ну хоть какой-нибудь хеш (ибо лишний поиск по дереву - это стильно, модно, молодежно), то почему бы просто не взять... та-дам: хеш самого объекта? Если бы автор читал предложения до конца, а не до того места, где желание нахамить становится нестерпимым, он бы заглянул в имплементацию той самой Мэп, которой он меня стращает, и увидел бы, что она именно так и поступает, дополнительно выравнивая дисперсию младших бит. Выражаясь проще, ей АБСОЛЮТНО ФИОЛЕТОВО, что там в ключе и даже какого он типа - она берет хеш объекта.
В сухом остатке приходим к печальному выводу: либо реальный ключ по логике задачи таки есть (и тогда его нужно просто использовать; который - полностью зависит от логики задачи), либо его нет, и тогда нефиг смешить людей и городить какие-то Мэпы там, где нужно использовать Лист, или, возможно, даже Сет. Вот в какие дебри могут увести домыслы и спекуляции... А, между тем, автор недвусмысленно уточнил: 6) не делайте предположений, и 7) отвечайте конкретно по вопросу, "задачу" оставьте мне.
Так что, думаю, наиболее разумное в сложившейся ситуации, это просто последовать этим мудрым заповедям и разойтись смеяться - каждый о своем :)
koi com: Спасибо, поржал от души :) Продолжайте в том же духе, и очень скоро вас ждет множество удивительных открытий относительно структур данных, одним из которых станет мучительное осознание абсолютной бессмысленности заданного вопроса и идеи генерации ключей только для того, чтоб они были. Учитывая разыгравшуюся бурю пронумерованных страстей, было бы просто негуманно лишать вас удовольствия сделать их самостоятельно.
koi com: Ну, Мап - это, вообще-то, структура данных для отображения множества ключей на множество значений. Если ключей в задаче нет (их приходится генерировать), то, вероятно, разумнее взять список, например, ArrayList, а не создавать искуственно проблему, которую потом героически решать :)
О чем вопрос, о java.util.Hashmap или о хешмап вообще? Если о первом, то она сама все генерирует. Как именно - достаточно заглянуть в исходник, в котором, заодно, подробно документировано, почему именно так и какие проблемы это решает.
Если вообще - то и ответ можно дать только общий: любым способом, подходящим для поставленных задач :)
И, да... "инкремент предыдущего" - это не хеширование.
Т.к. речь о двух разных девайсах, думается, достичь желаемого можно только на рутере, поместив WiFi и eth в разные сети и настроив iptable. Но без информации о прошивке рутера сказать что-то определеннее, действительно, проблематично :)
