Lenovo S860: особистий відгук і уточнені характеристики моделі 2014 року

У липні 2014 року мені доводилося користуватися чотирма активними номерами різних операторів. Кілька телефонів займали відчутне місце в сумці, тому я шукав спосіб зменшити кількість пристроїв.

Раніше придбаний Samsung Duos GT-S7562 у моєму користуванні швидко розряджався: за активного інтернету й Bluetooth-гарнітури працював приблизно 4–6 годин. Заміна батареї допомогла на певний час, але згодом мій екземпляр перестав працювати. Це історія конкретного пристрою, а не оцінка всіх телефонів марки.

Що я шукав

• Android і зручну роботу з інтернетом.
• Дві SIM-картки та підтримку Bluetooth-гарнітури.
• Щонайменше день роботи без заряджання в моєму режимі.
• Достатні мультимедійні можливості й прийнятну для мене ціну.

Розглядав моделі Philips і Lenovo. Зупинився на Lenovo S860, зокрема через позитивний попередній досвід із комп'ютерами й планшетом Lenovo.

Характеристики за документацією Lenovo

Офіційний огляд S860 дає змогу уточнити кілька неточностей початкової таблиці.

• Процесор — MTK 6582, чотири ядра, 1,3 ГГц.
• Екран — 5,3 дюйма, IPS, 1280 × 720, ємнісний, п'ять одночасних дотиків.
• Пам'ять — 2 ГБ RAM та 16 ГБ ROM у наведеній виробником конфігурації.
• Акумулятор — незнімний Li-Po, 4000 мА·год.
• Габарити — 149,5 × 77 × 10,3 мм; маса — 192 г.
• Два слоти SIM; мережі GSM 900/1800/1900 та WCDMA 900/2100.
• Wi-Fi 802.11 b/g/n, режим точки доступу; Bluetooth 3.0 HS; GPS з A-GPS.
• Камери — основна 8 Мп з автофокусом і спалахом, фронтальна 1,6 Мп.
• Початкова система — Android 4.2 Jelly Bean; у документі вказано тодішнє оновлення до Android 4.4 KitKat.

У первинній таблиці були зазначені 1 ГБ RAM, Li-Ion і Wi-Fi a/b/g/n. Вони не збігаються з конфігурацією в наведеному документі Lenovo. Для конкретного апарата слід звіряти його модифікацію.

Виробник наводив до 43 годин розмов у 2G, до 24 годин у 3G, до 28,5 дня очікування в 2G та до 40 днів у 3G. Це заявлені граничні значення, які не дорівнюють часу активного користування.

Перші дні користування

Під час налаштування виявилося, що мої SIM-картки потрібно адаптувати під Micro-SIM. Тоді я звернувся до «Київстару», де допомогли з картками й зміною тарифу. Згадка Mini-SIM у початковій таблиці суперечила цьому досвіду.

За перші один-два дні я встановив багато застосунків, увімкнув шифрування даних і досліджував SECUREit. У моєму тодішньому користуванні він пропонував перевірку застосунків, керування процесами та функції захисту даних. Набір таких можливостей залежав від версії ПЗ; я не мав підстав поширювати цей досвід на всі телефони Lenovo.

Екран виявився настільки зручним, що одного вечора я працював із телефоном замість ноутбука. Помітних уповільнень за перші дні не побачив.

Із двома SIM-картками, Bluetooth-гарнітурою, мобільним інтернетом, періодичним Wi-Fi та дзвінками мій телефон витримував понад 40 годин без заряджання. Саме такого результату я й хотів. На той момент був задоволений покупкою й сподівався на подальшу стабільну роботу. У липні 2014 року я навіть рекомендував S860 діловим користувачам: нарешті знайшов телефон, який відповідав моїм підвищеним вимогам.

«Корпорація 2» для обліку техніки: архів відгуків 2014 року

У липні 2014 року я почав збирати відгуки про нашу роботу над програмою «Корпорація 2». Тоді надійшли листи від працівників обласних інспекцій і торгових організацій. Найцікавіше в цих матеріалах — конкретні завдання, які люди виконували щодня: реєстрували техніку, друкували документи й шукали відомості про машини в інших регіонах.

Київський відгук: від книг обліку до електронного реєстру

У збереженій у блозі копії київського відгуку описано, як міська інспекція Держтехнагляду почала вести поточний автоматизований облік 5 травня 2003 року. Працівники паралельно переносили записи з паперових книг, які вели з 1996 року. Лише записів про реєстрацію техніки, за текстом відгуку, було понад сім тисяч. Оригінальну вебсторінку інспекції знайти не вдалося. Дати й цифри цього розділу походять зі збереженої копії.

Згадані у відгуку Правила державної реєстрації та обліку тракторів та іншої техніки затверджено наказом Мінагрополітики від 11 червня 2004 року № 221. Це нормативний документ того періоду. Він пояснює контекст обліку, а опис роботи програми й перенесення записів міститься у відгуку.

Як об’єднували районні бази

На першому етапі інспекції вели облік у районних і міських базах. За київським текстом, це дало змогу друкувати облікові документи, вести відомості про огляди й посвідчення трактористів-машиністів. Пошук машини або власника в іншому районі лишався окремою задачею. У відгуку початок робіт над централізованою системою під керівництвом Сергія Рудюка датовано березнем 2009 року.

Найскладніша частина перенесення була в самих даних. У районах використовували різні версії попередньої програми й різні довідники. Щоб записи можна було зіставляти, потрібно було узгодити значення довідників і перенести історію так, щоб пошук знаходив ту саму машину за її даними в різних джерелах. У київському тексті йдеться про можливість роботи інспекторів у спільній базі восени 2009 року. Цей опис стосується тодішньої системи.

Що користувачі відзначали в роботі програми

• Пошук техніки й власників, облік реєстрацій та перереєстрацій, зняття з обліку, видача посвідчень, опрацювання запитів і внесення відомостей про розшук чи арешт техніки.
• Єдині довідники, шаблони заяв, актів та інших документів, автоматичне формування звітів і оновлення програми.
• Індивідуальні облікові записи, згодом персональні ключі доступу, та історія змін. Це давало змогу встановлювати, хто вніс або змінив запис.
• Окремі сервери, резервні лінії живлення й інтернету, щоденне архівування, навчання та підтримка. У відгуку також згадано сайт Держтехнагляду і поштові скриньки в одному домені.

Практичний урок цього проєкту добре видно на прикладі районних довідників. Після імпорту варто звірити кількість записів по районах, перевірити кілька дублів вручну, надрукувати документ зі старої картки та знайти її із другого робочого місця. Так перевіряється і цілісність історії, і робота користувача після переходу.

Відгуки обласних інспекцій і торгових організацій

Сумська область

Кіровоградська область

«Техноторг-Дон»

ТОВ «ІКЦ Агротехекспертиза»

ТОВ «Дніпротехекспертиза»

ТОВ «Торговий дім «ДТЗ»»

ФОП Мельников

Дякую всім, хто поділився відгуками про нашу роботу. Для нас це дуже важливо.

Відновлення даних PostgreSQL через COPY: випадок із практики

Коли резервні копії давно не перевіряли, відновлення даних перетворюється на окрему задачу. Раніше я вже працював із відновленням Firebird та InterBase, але у липні 2014 року довелося шукати вихід із проблеми в PostgreSQL.

Помилки Page Error і резервна копія піврічної давнини

До мене звернувся давній клієнт: база PostgreSQL працювала в нього багато років, а напередодні під час входу в систему почали з’являтися помилки Page Error. Працювати стало неможливо. У pgAdmin я спробував створити резервну копію, але отримав помилки; вони виникали й під час переходу списком баз даних.

Вирішили відновитися з резервної копії. Виявилося, що остання була за грудень 2013 року: під загрозою опинилися приблизно пів року роботи. Тоді я спробував звичайний SELECT — і запит до потрібної таблиці успішно повернув дані. Ура! З’явився спосіб перенести доступну інформацію в окрему базу.

Як я переніс дані через COPY

1. Створив базу з іншою назвою та відновив у неї знайдену копію за грудень 2013 року. Перевірив вхід у застосунок — він працював.
2. Вивантажив дані з потрібних таблиць проблемної бази. Для однієї з них використав таку команду:

   copy (select * from zrp_zakaz ) to 'd:\tmp\zrp_zakaz';

3. У новій базі, відновленій зі старої копії, видалив попередній вміст відповідної таблиці перед завантаженням. Ця команда видаляє всі її рядки; у наведеному випадку вона виконувалася саме в окремій базі для відновлення:

   delete from zrp_zakaz;

4. Завантажив дані зі збереженого файла у відповідну таблицю нової бази:

   copy zrp_zakaz from 'd:\tmp\zrp_zakaz';

За результатом перевірки мені вдалося відновити роботу бази без виявленої втрати потрібної інформації. Клієнт був задоволений — саме цього й хотілося досягти.

Що важливо перевірити

Перед відновленням слід зберегти вихідний стан даних і працювати з окремою копією. Успішний SELECT до однієї таблиці не доводить цілісності всієї бази. Після перенесення потрібна перевірка повноти таблиць, зв’язків, послідовностей і роботи застосунку; під час експорту необхідно врахувати паралельні зміни даних.

COPY зі шляхом до файла працює на боці сервера PostgreSQL, а не комп’ютера з pgAdmin. Каталог має бути доступний обліковому запису сервера. Написання Windows-шляху й екранування зворотних скісних рисок потрібно звіряти з версією та параметрами SQL-сеансу. Наведені команди стосуються конкретної таблиці та шляху; перед виконанням їх потрібно звірити зі своїм середовищем.

Офіційний опис: COPY у документації PostgreSQL.

Матеріал «Корупція 2014»: повідомлення про перенесення

Статтю перенесено до тематичного блогу: pravdak.blogspot.com.

У цьому блозі залишено матеріали з програмування, адміністрування й техніки.

У цьому записі збереглося лише повідомлення про перенесення. Посилання веде на головну сторінку тематичного блогу; повного тексту перенесеної статті тут немає.