pi314

Вы не попутали часом CSS с SVG ? Потому, что CSS - это не про фигуры, а про стили и свойства элементов DOM :)

Отношение изменилось от того, что большинство юристов, в отличие от большинства ИТ-шников, изучают философию и знакомы с законами диалектики, один из которых (почерпнутый Энгельсом у Гегеля) гласит, что количество неизбежно превращается в качество :)

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

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

Начните отсюда, чтоб проверить, не пропадет ли интерес так же быстро, как и возник: Тыц Тыдыц

Если не пропадет, смотрите исходники KiCad.

LIMIT имеет смысл только в сочетании с ORDER BY. Например, выдать конфетку трем победителям:

UPDATE users SET candy=candy+1 ORDER BY score DESC LIMIT 3

В качестве информации к размышлению: слово "пропорционально" означает линейную зависимость, как между объемом и массой жидкости. А что конкретно означает "нагрузка", вообще непонятно; нагрузка на сеть? на процессор? на нервную систему админа?

Хотя, если рассмотреть некую полную сферическую нагрузку в вакууме, то нужно быть полным кретином, чтоб спроектировать систему, в которой она будет ЛИНЕЙНО зависеть от количества пользователей. К счастью, это довольно трудно :)

//Проверяем, не ЗАБЫЛ ли пользователь ввести свое имя?
if (name == null || name.trim().isEmpty()) { ...

такая "хитрая" проверка нужна, т.к. readLine() вполне может вернуть null, и тогда мы упадем по NPE на name.trim()

В Джава сравнение строк делается так
if (name.equals("Вася"))
a name=="" сравнит объект name с другим, новым объектом типа String, со значением "" ... которые, разумеется, никогда не будут равны (вне зависимости от того, равны ли между собой ЗНАЧЕНИЯ строк), ибо это два разных объекта!

Поменяйте батарейку (это в любом случае нужно сделать).

Если проблема сохранится, придется поменять "пересохшие" электролитические конденсатоы... впрочем, сомнительно, что последнее вообще имеет (экономический) смысл для такой древней железяки :)

Причина - старение (возможно, ускоренное разовым или периодическим нагревом "выше среднего") :)
В ближайшем будущем встречайте "загадочные" проблемы при старте, которые исчезают, если стартовать с зарядкой, но БЕЗ подключенной батарейки. Самое позднее тогда придется таки заменить батарейку.

Копать в сторону IMAP.

Update:
Судя по уточняющим вопросам, нужно таки немного разжевать.

SMTP, как, впрочем, и PHP, тут совершенно сбоку. Функционал "отправленные" реализуется либо мэйлером (локально), либо провайдером. Во втором случае это просто папка на сервере. Как конкретно в нее попадает копия, одному провайдеру известно. В любом случае, по SMTP нельзя получить доступ к папкам - можно просто сбросить письмо, и надеяться, что оно будет доставлено.

Совсем другое дело IMAP. По IMAP можно получить доступ к папкам и, например, самостоятельно откладывать копию в соотв. папку, после того, как письмо успешно ушло по SMTP.

SMTP к этой истории имеет лишь то отношение, что он обычно осуществляет (если осуществляет) авторизацию пользователя.

Могу ошибаться, но у 3.7V LiPo максимально допустимое напряжение зарядки 4.2 (4.22) V. Кроме того, при зарядке нескольких элементов обязательно нужна балансировка. Короче, без схемы сказать что-то наверняка трудно, но прямое подключение к USB вполне реально может завершиться вздутыми/взорвавшимися батарейками и/или убитым USB.

P.S. По внешнему виду провода похоже, что "примочки" там встроены прямо в штекер USB.

P.P.S. 7.4 / 3.7 = 2 (элемента)

LIBXML_COMPACT ?
А, вообще, проблема, похоже, архитектурного плана. Если файлы небольшие, то время, в основном, расходуется на выкачивание по HTTP. Выкачайте 20 файлов, положите на диск и сравните производительность. Если подтвердится, поможет только какое-нибудь умное предварительное кеширование.

Причина в том, что в (дешевых, низкого качества) материалах, из которых изготовлены эти части, содержится много т.н. пластификаторов, типа DEHP. Эта штука не вступает в химические соединения с материалом и со временем просто выходит на поверхность. (Кстати, конкретно DEHP, при "принятии внутрь" весьма вреден для почек, печени и половых органов и в Европе запрещен, по крайней мере, в детских игрушках и упаковках для пищевых продуктов. Но не пугайтесь - в конкретном случае это могут быть и другие, более или менее вредные химикалии.) Сам процесс "таяния" ускоряется под воздействием, прежде всего, солнечного света (ультрафиолетовое излучение), вызывающего в эластомерах фотохимические реакции.

Что конкретно можно сделать. "Размочить" липкую массу WD-40 и удалить с поверхности механически, после чего не забыть тщательно вымыть руки.

С поролоном несколько иная история, но - та же мораль: поможет только замена материалов на более качественные.

P.S. На всякий случай - я ни разу не эксперт в материаловедении, просто случайно сталкивался с проблемой по работе и пересказываю объяснения экспертов "своими словами".

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

Запуск и работа в фоновом режиме;
Через определенные равные промежутки времени
считывает GPS координаты
и отправляет их через Сеть на сервер
если при отправке нет (или же совсем нет) Сети, то отправлять на заданный телефонный номер...

Но начать придется все равно отсюда, после чего перейти сюда.

Не совсем в тему, но есть т.н. техника "мертвых душ". Впервые была придумана для телефонных справочников. Суть в том, что в публично доступные данные намеренно вносятся безвредные ошибки, например телефон несуществующего Васи Пупкина, проживающего по несуществуюшему, но правдоподобному адресу. Безвредные, т.к. при использовании справочника по заявленному предназначению (intended use) никто не станет искать телефон Васи и, следовательно, не пострадает от его "неточности".
Если же кто-то попытается несанкционированно скопировать справочник, распознавание и удаление таких маркеров сопоставимо по трудозатратам с самостоятельным сбором данных, что делает затею бессмысленной.

С точки зрения бухгалтерии есть и третий, правильный вариант: остаток = доступный + зарезервированный товар. Положили в корзину = зарезервировали. Оплатили -> ничего не делать. Оплата не прошла = "разрезервировали" и принудительно выкинули из корзины.
А остаток, как таковой, уменьшать только по факту отгрузки (накладная).

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

item_name (id, name);
item_user_price(id_user, id_item, price);

В первой будет "более 200" записей (которые, кстати, со временем могут удаляться / добавляться), во второй - столько, сколько цен будет вводиться пользователями (сомневаюсь, что пользователи будут рады, вводить все 200 цен за раз; а может у кого-то вообще есть не все цены).

Такая структура даст минимальную избыточность. Но будет ли она "оптимальной" по скорости и расходу памяти, зависит от конкретных запросов, которые на ней будут выполняться.

Короче, как-то так:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:ns="http://meinMuseum.de" targetNamespace="http://meinMuseum.de"
  elementFormDefault="qualified" attributeFormDefault="unqualified"
  xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" vc:minVersion="1.1">

  <xs:simpleType name="RestrictedString4to20">
    <xs:restriction base="xs:string">
      <xs:minLength value="4" />
      <xs:maxLength value="20" />
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="Autor">
    <xs:simpleContent>
      <xs:extension base="ns:RestrictedString4to20">
        <xs:attribute name="id" type="xs:positiveInteger" use="required" />
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name="EvenInteger">
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="0" />
      <xs:assertion test="$value mod 2 = 0" />
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="HexBinary">
    <xs:restriction base="xs:string">
      <xs:pattern value="W[1-9a-f]+[0-9a-f]*" />
      <xs:length value="10" />
    </xs:restriction>
  </xs:simpleType>

  <xs:element name="museum">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="werk" maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="type">
                <xs:simpleType>
                  <xs:restriction base="xs:string">
                    <xs:enumeration value="Buch" />
                    <xs:enumeration value="Multimedia" />
                    <xs:enumeration value="Zeitung" />
                  </xs:restriction>
                </xs:simpleType>
              </xs:element>

              <xs:element name="autor" maxOccurs="unbounded"
                minOccurs="0" type="ns:Autor" />

              <xs:element name="jahre" maxOccurs="unbounded">
                <xs:simpleType>
                  <xs:union>
                    <xs:simpleType>
                      <xs:restriction base="xs:integer">
                        <xs:minInclusive value="-100" />
                        <xs:maxInclusive value="2012" />
                      </xs:restriction>
                    </xs:simpleType>
                    <xs:simpleType>
                      <xs:restriction base="xs:string">
                        <xs:enumeration value="AB" />
                        <xs:enumeration value="BC" />
                        <xs:enumeration value="after2000" />
                        <xs:enumeration value="unknown" />
                      </xs:restriction>
                    </xs:simpleType>
                  </xs:union>
                </xs:simpleType>
              </xs:element>

              <xs:element name="referenz" maxOccurs="unbounded"
                minOccurs="0">
                <xs:complexType>
                  <xs:attribute name="refid" type="ns:HexBinary"
                    use="required" />
                </xs:complexType>
              </xs:element>

              <xs:element name="bearbeiter" type="ns:EvenInteger" />
            </xs:sequence>

            <xs:attribute name="bezeichner" type="ns:HexBinary"
              use="required" />
            <xs:attribute name="erfassung" use="optional" type="xs:date" />
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

P.S. Надеюсь, это не в берлинском TU такое задают :)

Проверить, есть ли у пользователя, под которым выполняется Eclipse, права на папку вообще, и на запуск adb в частности!

update:
Если с правами все ОК, возможно, нехватает некоторых i386 пакетов:

dpkg --add-architecture i386
aptitude update
aptitude install libstdc++6:i386 libgcc1:i386 zlib1g:i386 libncurses5:i386 libsdl1.2debian:i386 lib32z1

Правильный подход в объектном дизайне - не плодить сущности без нужды! "Красота", сама по себе - это не причина. Причина может быть в том, что, например, дома и пары координат где-то агрегируются в отдельных списках, в которые не хочется тащить ненужный хлам.

А кроме того, если данные будут персистироваться, например, с помощью ORM, или сериализоваться, например в JSON, то всякое разделение - это дополнительный join с вытекающей отсюда потерей производительности/памяти и т.д.

Если все же есть реальные оправданные причины разделять сущности, то правильно делать так:

class House{
  private String number; // номер дома
  private String kladrCode; // код КЛАДР дома
  private String entrance; // подъезд

  public String getNumber(){ return this.number;}
  public String getKladrCode(){ return this.kladrCode;}
  public String getEntrance(){ return this.entrance;}

  public void setNumber(String number){ this.number = number;}
  public void setKladrCode(String kladrCode){ this.kladrCode = kladrCode;}
  //  и т.д.
}
class AddressParcel {
  private String streetType; // название типа улицы (улица, проспект, бульвар и т.д.)
  //...
  private House house = null; // это не обязательно, но "хорошая практика" - явно инициализировать объектные поля статически!
  // ...
  public House getHouse() { return this.house;}
  public void setHouse(House house) { this.house = house;}
}

А доступаться - вот так:

String someType = someAddress.getStreetType();
String someNumber = someAddress.getHouse().getNumber();

И еще: типы данных (одни стринги!) наводят на некоторые нехорошие размышления...