Программирование
Языки программирования, алгоритмы, фреймворки, библиотеки и тому подобное
Рубрикатор
Последние записи
INat::Get — ранняя альфа
— Я зделяль. ©
Итак, прошу любить и жаловать — INat::Get — софтина для получения и обработки данных с iNaturalist. Основное изначальное предназначение — подбивать всякую статистику для проектов на том же iNaturalist’е, но варианты использования гораздо шире.
Первым делом хочу отметить, что текущее состояние — это ранняя альфа. Я не рекомендую никому этим пользоваться иначе как из любопытства и желания поучаствовать. Тем не менее делаю пост уже сейчас в надежде, что любопытные желающие найдутся. Со своей стороны готов подробно отвечать на вопросы и учитывать пожелания.
Зачем?
iNaturalist предоставляет открытый доступ к огромному массиву наблюдений, а также по сути к постоянно актуализируему таксономическому справочнику (тут можно обсуждать нюансы, но для любительских целей это очень хорошие данные). Интерфейс самого сайта не покрывает и, конечно, не может покрывать все возможные варианты запросов и выборок, но мы можем получить сами данные через механизм выгрузок или посредством открытого API, и второй вариант богаче, гибче и вообще интересней.
Паникуем иначе
В недавнем посте я в основном сосредоточился на том, как развитие нейросетей и прочих элементов ИИ повлияет на рабочие процессы. И я действительно не вижу поводов для паники в этом отношении. Но это совершенно не значит, что приход новых технологий не несет с собой неприятностей другого плана. Как это собственно бывает с, наверное, любыми новыми технологиями.
О некоторых я там кратко упомянул, но не особо вдаваясь в детали, разве что про поисковый спам чуть развернул мысль, но это потому, что замусоренность информационного пространства сильно влияет и на профессиональную деятельность.
Сейчас мне бы хотелось поговорить о темной стороне использования новых технологий. Именно в способах использования, злоумышленных, или наоборот — малоосмысленных, я предполагаю некоторые потенциальные проблемы. И сразу замечу, что я далек от киберпанка и всяческого турбоапокалипсиса. Я вообще технооптимист.
Отставить панику...
С выходом ChatGPT как-то внезапно обострились апокалиптические настроения в духе: заменит программистов, оставит нас всех без работы, и прочее «мы все умрем». Последнее, конечно, верно, но не ново.
Сразу скажу, что самолично я с ChatGPT не экспериментировал, так что размышлять буду в целом отвлеченно-теоретически, опираясь, впрочем, на множество «свидетельских показаний» в интернете, касающихся как этой нейросети, так и разных прочих.
Попробую сделать некоторые предположения, как именно в действительности нейросети нового поколения повлияют на различные виды деятельности (те, о которых я имею хоть какое-то представление). Если коротко, то убийства интеллектуальных и творческих профессий я не ожидаю, при этом изменения таки будут, и будут существенны, причем наиболее существенные проявятся в долгосрочной перспективе.
И да, КДПВ сгенерирована нейросетью по запросу «deep learned girl in fantasy style».
xbash
Давно собирался и таки стартанул пет-проект — https://github.com/shikhalev/xbash.
Навеяно gitsh, который я когда-то активно использовал, но у него были проблемы с русской локалью, новыми версиями Git и так далее. При этом, на мой взгляд, gitsh сильно переусложнен, да и использование Ruby, при всей моей любви к этому языку, тут лишнее. Посему я решил сделать что-то подобное, но попроще, на чистом bash, и более универсальное.
Что делает?
Итак, что этот скрипт (набор скриптов) делает?
-
Позволяет использовать субкоманды того же
git, как непосредственные команды. Помимоgit, так же можно коротким образом вводить субкомандыcargo1. -
Отображает в приглашении командной строки репозиторий, ветку, путь внутри репозитория и значок статуса (звездочка разных цветов на данный момент). Кроме того, вместо имени локального пользователя показывается e-mail пользователя, под которым идет запись в репозиторий2.
-
Другие системы управления версиями, сборки и управления зависимостями могут быть добавлены просто и единообразно. Для Mercurial и Rubygems планирую сделать, как только руки дойдут.
Стадия разработки пока самая ранняя (хотя я уже пользуюсь и отлаживаю «наживую»), поэтому инсталлятора нет, есть инструкция по установке в файле README.md.
-
Если кто не знает,
cargo— это система сборки и управления зависимостями языка Rust. ↩ -
Для меня отображение именно пользователя репозитория, а не локального, довольно существенно, поскольку на данный момент я работаю из дома и у меня имеются как личные, так и рабочие проекты, которые нужно вести под разными аккаунтами. ↩
Отчет о рефакторинге
](/img/2021/07/09/refactorig-report/jekyll-screen-fhd.webp "Скриншот с [официального сайта Jekyll](https://jekyllrb.com/)")
Итак, я таки отрефакторил и обновил данный сайт. Почему нельзя было сразу делать правильно? Ну, в основном потому, что я впервые имел дело с Jekyll, изрядно подзабыл (а что-то и не знал) базовые приемы верстки… И так далее, и тому подобное.
Вторая (в моем случае) причина — это то, что, как это часто бывает, представление о желаемом результате уточнялось и формировалось в процессе достижения результата просто работающего. Соответственно, решение «исторически сложилось», если вы понимаете, о чем я. Любой проект ставит разработчика перед выбором: или бесконечное (и потому бесплодное) делание «как надо», или движение к идеалу через неидеальные, зато рабочие, варианты, которые, впрочем, без регулярного рефакторинга быстро становятся неулучшаемым и иногда не совсем рабочим болотом.
Но на самом деле этот пост не только, и не столько о рефакторинге как таковом, сколько о технической стороне этого сайта в целом. Благо, сразу после выкатки первого варианта я так технический пост и не написал, желая сначала получше разобраться. Вот, сейчас и пишу о том, с чем разобрался, и о процессе этого разбирательства.
Небольшой подводный камень в Rust
Обнаружил тут некоторый подводный камень в стандартной библиотеке Rust. Багом это назвать, конечно, нельзя, просто такой момент, где можно по собственной невнимательности наступить на грабли и не сразу это заметить, что нехарактерно для Rust.
Опасность подстерегает нас, когда мы читаем данные из файла посредством std::fs::File.read()1, не используя
при этом std::io::BufReader2, а самостоятельно выделяя блок памяти и читая в него.
Подводный камень тут вот в чем, цитирую документацию:
if
nis0, then it can indicate one of two scenarios:
- This reader has reached its “end of file” and will likely no longer be able to produce bytes. Note that this does not mean that the reader will always no longer be able to produce bytes.
- The buffer specified was 0 bytes in length.
Подчеркивание мое. Итак, если мы передаем методу read() буфер нулевой длины, то результат будет ровно тот же самый,
что и если мы достигли конца файла, т.е. Ok(0).
Rack — основа веб-фреймворков в Ruby
Оригинал этой статьи опубликован в журнале «Системный администратор» №5 (150) за май 2015. Прошу обратить внимание на год — какие-то моменты могут расходиться с современными версиями языка и библиотек…
Библиотека Rack — простой объектный интерфейс для написания веб-приложений.
Слово «rack» в английском языке имеет множество значений, включая такие, как «пытка» и «разрушение»… Однако, надо полагать, название рассматриваемой библиотеки произошло от другой группы смыслов: «стойка», «штатив», «каркас» и т.д. Rack обеспечивает простой и в то же время удобный интерфейс, обеспечивающий взаимодействие между веб-сервером и приложением, позволяя программисту сосредоточиться исключительно на логике последнего.
Этот интерфейс достаточно низкоуровневый и не ограничивает разработчика каким-либо заранее заданным способом организации приложения и высокоуровневыми абстракциями. Соответственно, он и не предоставляет таких абстракций — это уже дело фреймворков, которые работают поверх него: Rails, Sinatra и других.
Всё для людей!
Ковыряюсь тут с PostgreSQL и вот какую замечательную штуку обнаружил…
Собственно, про существование «updatable views» я знал, и давно. Но пока не доводилось использовать. И я думал, что для того, чтобы они заработали, нужно прописывать правила для всех действий. Однако нет — простые представления делаются изменяемыми автоматически, т.е. пишем, например:
create table something_data (
id bigint not null,
name varchar(200) not null,
deleted boolean not null default false,
constraint pk_something primary key (id)
);
create unique index uq_something_name on something_data(name)
where (deleted = false);
create view something as
select id, name from something_data
where deleted = false;… и всё, этого достаточно — можно обращаться к представлению something так же, как к таблице — вставлять,
изменять, удалять по id.
Средства самопознания в Ruby
Оригинал этой статьи опубликован в журнале «Системный администратор» №1-2 (146-147) за февраль 2015.
Что программа может знать о самой себе?
Практически все современные языки программирования содержат средства, позволяющие во время выполнения программы получить какие-то данные о структуре самой этой программы. В компилируемых языках такие возможности, как правило, ограничены и отключаемы, в целях оптимизации, в интерпретируемых же более обширны, поскольку эти данные все равно необходимы самому интерпретатору, соответственно, содержатся в памяти, и вопрос только в том, предоставлять ли к ним доступ языковыми средствами.
В данной статье я планирую рассмотреть те средства «самопознания», которые доступны для программ на Ruby.
Метапрограммирование в Ruby: разбор примера
Оригинал этой статьи опубликован в журнале «Системный администратор» №12 (145) за декабрь 2014.
Добавление собственных абстракций в объектную модель — это просто. И интересно.
Авторы книги «Programming Ruby: The Pragmatic Programmers’ Guide» называют метапрограммированием расширение и изменение абстракций языка (тогда как собственно программирование пользуется теми, что есть). Конечно, можно поспорить о том, что считать такой абстракцией, а что нет, однако нельзя не заметить, что в современных динамических языках, таких как Ruby или, например, Python, легко делаются некоторые вещи, которые в классических языках находились именно на языковом уровне и жестко определялись компилятором. Тут можно вспомнить, для примера, декораторы, о которых я писал в сентябре прошлого года1. И сейчас мы рассмотрим нечто подобное. В процессе я буду делать обобщающие отступления, переходя от частного примера к общим принципам программирования в Ruby.
-
Статья «Декораторы в Ruby». «Системный администратор» № 9 (130), сентябрь 2013. Стр. 68–71. ↩
Показаны 10 записей из 28