Category: it

Category was added automatically. Read all entries about "it".

манул

Эмулятор ДВК

Эмулятор ДВК

... Обновилась текущая сборка "эмулятора ДВК": DVK_Emulator_10.08.17_02-48, являющегося побочным продуктом разработки модульного API эмуляции. Изменения: 1. Теперь обновление каталога Windows, подключенного к приводу HD, производится при каждом чтении каталога виртуального диска и через 0.3 секунды…

Posted by Юрий Финкель on 4 сен 2017, 07:05

from Facebook
манул

окончательный текст

Привёл в ЖЖ и dreamwidth тексты перевода Козинга в соответствие с окончательной версией. Правда, был ещё перепост, в котором сохранилась самая первая черновая версия, в которой весьма корявый стиль и есть несколько прямых переводческих ошибок. Ну да и ладно.

На всякий случай продублирую здесь:

Текст книги в html:
http://esperanto.mv.ru/Marksismo/Kosing/index.html

Текст в html одним файлом для скачивания:
http://esperanto.mv.ru/Marksismo/Kosing/kosing_stalinism.zip

Текст в fb2:
http://esperanto.mv.ru/Marksismo/Kosing/kosing_stalinism.fb2.zip

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


Комментариев: comment count unavailable  Комментировать
манул

(no subject)

К дню программиста. Уже вторую (если не третью) неделю у меня идефикс написать переключалку клавиатуры моей мечты (для виндов, т.к. под ними я живу). Пишу на AHK (AutoHotKey). И вот есть один затык, который лично для меня не важен. но заради универсальности... Короче, никак не удаётся под Windows 10 определить текущую раскладку клавиатуры для _консольного_ приложения. Нашёл было способ, но он базируется на недокументированной функции WinAPI GetConsoleKeyboardLayoutName, которая работала в Windows 7, а в Windows 8 и тем более 10 уже не работает. И главное, гугленье (многодневное!) ничего не даёт - все только жалуются, что, мол, никак, и никто не знает ответа. А те кто знает, ЧСХ, молчат. А то, что есть те, кто знает - без сомнения, т.к. всякие там Punto Switcher'ы нормально определяют раскладку и у консольных окон.

И ведь не то чтоб мне это было сильно нужно - я использую FAR с ConEmu, а он сам эмулирует консоль и там можно использовать обычный способ для обычных гуёвых окон. Но заело меня, хочу разобраться. Маньячу вот потихоньку, чуть ли не всё свободное время... Сам знаю, что дурью маюсь, но заело.
манул

новый сайт IKEK (Internacia Komunista Esperantista Kolektivo)

http://ikek.org/

Картина художника Ю. Ф. Холст, масло PHP, jQuery. Собственная система управления контентом, написанная на коленке за неделю по вечерам. (Пока что управляется просто редактированием файлов, но задумано дальнейшее развитие для ввода статей через веб многими пользователями).

С содержанием там пока что слабо (мягко говоря). Планирую перевести туда кое-что из "Энциклопедии марксизма".

Хотя всё равно бесполезно.
манул

за что я не люблю unix

Точнее, не сам по себе Unix, а подход к программному обеспечению, стиль, сложившийся вокруг него, который вполне себе проявляется и во многих программах под Windows (чаще - перенесённых с линукса, но не только).

Вот понадобилась мне программа, перекодирующая видео (для дома, для семьи, а отнюдь не для работы). Нашёл я программу, которая удовлетворяет моим требованиям - avidemux. Всё, казалось бы, замечательно, но хочется режима пакетной обработки (перекодировать сразу пачку видео - для сериалов, например). Хотя бы чтобы из командной строки задать, чтобы батник написать. И вроде бы всё в документации про это написано, делаю в точности как написано - не работает. Это уже напрягает, ибо я в отпуске и компьютерные дела такого рода мне осточертели на работе (где они занимают процентов 50 рабочего времени). Ладно, концентрирую расслабленный мозг и лезу на форум программы (англоязычный, естественно). И что я вижу? Оказывается, документация, которую я читал, касается старой версии программы (2011 год). И в старой версии программы скриптовым языком, с помощью которого задавались все параметры пакетной работы, был js (javascript). А теперь, оказывается, они заменили его на Питон!!! При этом полностью выкосив поддержку старого языка, и это при полном отсутствии документации к новой версии программы! И старая версия программы на официальном сайте отсутствует!

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

Вот это и есть unix-подход: программы пишутся для тех, кто может в них разобраться после прочтения кучи мануалов и/или многочасовых проб и ошибок. Да, я, чёрт возьми, программист с 30-летним стажем, да, я могу в этом разобраться (и разобрался в конце концов). Но мне жалко своего времени! Я не красноглазый линуксоид, получающий удовлетворение от секса с gentoo. Я хочу ткнуть кнопку и получить результат, не задумываясь. Я на работе думаю, уже все мозги себе проел. Я просто хочу дома видео посмотреть!

И вот так у них (unix) всё.
манул

(no subject)

Такого жутчайшего бардака с представлением даты и времени, как в Java, я больше нигде не видел. Это просто вредительство какое-то. Вчера это прямо вывело меня из себя.

Мало того, что в классе java.util.Date почти все методы объявлены deprecate (я обычно на это плюю и использую их, ибо удобно), мало того, что рядом с Date есть ещё извращённый класс GregorianCalendar (это при том, что не грегорианских календарей всё равно там нет), который обычно рекомендуется использовать (хотя использовать его неудобно). Так ещё и при попытке использовать тип date в базе данных (PostgreSQL) через JPA этот тип на серверной стороне отображается в java.util.Date, а на клиентской какого-то рожна - в третий класс XMLGregorianCalendar, который не совместим ни с одним из вышеперечисленных, чтобы выдрать из него информацию, нужно извращаться, а вот записать мне вообще так и не удалось. То есть с некоторым извратом на клиентской стороне я помещаю в него нужную дату, но на серверную сторону эта сволочь в любом случае передаёт null. То ли там какое-то из полей не дописано, то ли надо было мудрить с аннотациями, чтобы дата отображалась на нужный мне тип...

В общем, плюнул я на это и переделал таблицу в БД на использование unix time (секунды после 1.1.1970, int8, отображающееся на long). Правда, приходится делить/умножать на 1000, т.к. явский Date внутри себя имеет миллисекунды, но это уже мелочь по сравнению с вышеперечисленным.

Я возмущён: какие индусы писали эту часть API? И главное, всем, кажется, по фиг, хотя это широко известная проблема (судя по гуглу). Видимо, все так же, как и я, используют unix time.

Короче, вывод: при работе с Явой нужно в базе данных избегать типов date, time, timestamp и т.п. любой ценой.
манул

фух...

Завтра — в отпуск.

А сегодня доделываю последние (ну или предпоследние) штрихи к программе, над которой корплю уже два с половиной года (вот мой пост от 4 февраля 2012 — это самое начало работы). Если быть точным, это третье поколение системы, над которой я работаю уже лет 8. Первое поколение было написано на PHP и MySQL, второе — на Java + SmartGWT и MySQL и работало через веб-интерфейс (но этот путь показал себя тупиковым), а вот теперь третье, написанное на Java EE + Swing + NetBeans Platform и PostgreSQL. Естественно, каждое поколение было написано с нуля, но с учётом опыта предыдущих. Причём первое и второе поколения до сих пор работают (у них несколько разная область применения), а нынешнее, третье, сейчас пойдёт в тестирование и опытную эксплуатацию, и после доработки и исправлений ошибок (где-то через полгода) заменит второе поколение.

Программа предназначена для автоматизации рабочего места риэлтера. В общем, ничего особенного она из себя не представляет, просто в ней уж очень много всего.

Вот, например, неполный список сущностей (и соответственно, таблиц базы данных), с которыми работает программа: задачи, события, объекты недвижимости, агенты, фирмы, контрагенты — физические лица, контрагенты — юридические лица, сообщения, услуги, этапы... Всё это взаимосвязано между собой достаточно хитрым образом. Например, задачи могут иметь подзадачи (любого уровня вложенности), т. е. организованы древовидно. К ним могут прикрепляться объекты (не более одного), события, агенты, контрагенты, сообщения... К любой сущности (т. е. к задаче, объекту, агенту и т. д.) могут быть прикреплены вложения (фото, видео, документ, вообще любой файл), а также метки (или тэги), по которым производится быстрая фильтрация. Сообщения (фактически внутренняя электронная почта) тоже организованы древовидно (с ответами), они могут ссылаться на задачи или объекты. И т. д. и т. п.

И всё это вместе бегает и крутится, местами даже асинхронно (чтобы не блокировать всю программу на долгих операциях). Естественно, по "трёхъярусной" архитектуре: клиент — сервер приложения — сервер базы данных.

Клиент: 83 класса (*.java), 1.4 Мб исходного текста, примерно 32000 строк.
Сервер: 82 класса (*.java), 550 Кб исходного текста, примерно 17000 строк.
Всё вместе: 165 классов, почти 2 Мб исходников, около 50000 строк.

Это не считая некоторого количества скриптов на groovy, обслуживающих программу.

Может быть, два с половиной года для такой программы — слишком долго, но писал её я практически один (мой непосредственный начальник, он же сисадмин, он же постановщик задач, непосредственно в кодировании участия не принимал, хотя руководил разработкой и генерировал идеи), к тому же с перерывами на другие задачи. К тому же в процессе работы я изучал Swing, Java EE и EJB, с которыми ранее дела не имел.

В общем, хотя с одной стороны я эту работу в гробу видал и жду — не дождусь выйти на пенсию (ещё 10 лет осталось), но с другой стороны — есть некоторое законное удовлетворение от завершения большого дела. Ну как сказать, завершения... Конечно, ещё как минимум полгода, а то и год, придётся программу дорабатывать напильником — в процессе эксплуатации полезут баги и пожелания пользователей. Но основное сделано.
Пин: компрессия!

схема раскраски groovy-скриптов для Colorer

Поскольку я постоянно пользуюсь FAR'ом, то и небольшие файлы и скрипты редактирую непосредственно в нём. В редакторе FAR'а есть очень полезный плагин Colorer (в последних версиях он даже стал поставляться в дистрибутиве), который раскрашивает исходные тексты программ на разных языках. По работе мне в последнее время понадобилось работать с языком Groovy, и я с удивлением обнаружил, что поддержки Groovy в Colorer нет (хотя есть огромная куча языков, даже экзотических, от Кобола до Ска́лы, от PL/1 до Эрланга).

Когда-то я разбирался с настройками и прочими потрохами Colorer'а (в пору работы над моим UniRed'ом, который его использует), но за прошедшие 10 лет основательно подзабыл, да и Colorer с тех пор несколько изменился.

В общем, вот результат нескольких дней проб и ошибок, забирайте, если кому надо:

https://www.dropbox.com/s/l49xvayoeroqqoj/groovy-hrc.zip

(Для тех, кто, как и я, будет пытаться продраться через невнятную документацию Colorer'а на ломаном английском и тучу запутанных hrc-файлов для других языков, сформулирую очень кратко основной принцип: в правиле <block> атрибут region описывает, как по умолчанию нужно раскрашивать заданную область, а атрибут scheme указывает, где нужно брать дальнейшие правила для раскраски внутри заданной области).