「OSS」の記事 - Crieit

LINE風LINEトーク履歴ビュアーを作った話

2021-04-20T16:55:41+09:00

LINEで「トーク履歴を送信」で取得できる味気ないトーク履歴をLINEのトーク画面風の見た目に変換するWebアプリケーションをだいぶ前に作りました。
せっかくなのでどこかで披露したいと思いポストします。

hidao80/LINEBackupViewer： LINE風LINEバックアップテキストデータビュアー - github.com
https://github.com/hidao80/LINEBackupViewer

てんまつ

Qiitadonにて発生したつぶやきにリアクションがあったのが発端。

curatiodon - キュレーショドン | Mastodonまとめwebアプリ
https://git.io/Jk196

つかいかた

http://hidao80.github.io/LINEBackupViewer/にアクセスしてトーク履歴のテキストファイルをアップロードするとプレビューされます。
「ダウンロード」ボタンを押すとプレビューされた内容をそのまま単一のHTMLファイルにして保存することができます。

また、アップロードされるのはご利用のブラウザまでで、サーバにトーク履歴が保存されることはありません。

※画面は開発中のものです

今のところ1対1のトーク履歴しか再現できず、複数人トークのユーザ切り替えは宿題になっています…

フリーソフトウェアの布教活動の動機；創作行為の大衆化と湾曲的自己表現による批評合戦の活性化

2020-03-14T23:37:05+09:00

仕事も大分落ち着いたので、大衆には無益有害だが、ごく個人としては心にとどめておきたい、
「私が生存するに当たっての目的」
みたいなものをここに書き留めておく。

フリーソフトウェアはロマンがある

ここでいう フリーソフトウェア とは、ほぼ「オープンソースソフトウェア」と同意味ではあるものの、厳密には 自由ソフトウェア の事を指している事には留意していただきたい。
「Free Beer」ではない。「Free Speech」である1。

とはいえ、筆者は純粋な GNU/Linux を使っている訳でもなく、Ubuntu 上のSteamでUndertaleを普通に遊んでいる Not Pure Free Software Fanatic なので、そんな肩ひじ張らずに読んでいただいて問題ない。

インターネットに繋がっていれば問題なく手に入る

今日、比較的田舎の町でも 4GLTE 回線であれば 20Mbps 程のデータのダウンロードは行える時代となった。なのでフリーソフトウェアに限らず、無償のソフトウェアは気軽に入手できると言っていいと思う。

そのため、最悪キーボードのみ、できればマウスも、必要があればペンタブレットや MIDIキーボードがあれば、パソコンを利用して部屋を散らかさずに創作活動ができるものだと考えている。

知識があれば拡張もできる

ソースコードの改変が許されるソフトウェアであれば、その利用者が機能拡張することだって許されるのである。

これにより、ソフトのユーザーが独自に拡張を行って効率を飛躍させることもでき、さらにはその機能を共有すると助かる人が居ることもよくある話である。

フリーソフトウェアそのものが興味深く楽しい

フリーソフトウェアそのもの自体もとても興味深いものである。

なぜかと言えば、そのフトウェアのソースコードは、コンピューターの扱い方のレシピブックでもあると捉えられるだろう。

さらに言えば、そのソフトウェアを取り巻くコミュニティもまた興味深い。

たまに悪意を持ってプログラムを改変する人もいるが、比較的善意や純粋な知的好奇心でそのプログラムを改変し、共有している人々もいる事実がある。

自由に創作できるという事

良い時代になったものである。しかしそんな環境下に居るにも関わらず、創作活動をしない人が居るのも事実である。

強制はしない。しかしもったいないと思ってしまうのが筆者の心情である。

せっかく道具は（質は置いておく。各個人の肌感覚もあるし）気軽に入手できるのだから、やればいいのにとつい思う。

ましてや共有できる環境も比較的増えたわけだし、感情や考えを分かち合う……というのも大げさなのではあるが、そういう事をしたいと思うのであれば、晒してみるのもまた一興、うるさいガヤの小言を聞きたくないなら、ベタなHTMLとCSSと少々のJavaScriptで構成したWebページを自分で作り、どこかにアップロードすると良いと思う。

ましてや今日、Web上に転がっているコンテンツなら8割は収集しているであろうサーチエンジンや、どうしても一言申し上げたい輩が居るのならSNSにリンクを貼って共有したらいい話だと個人的には思う。

とはいえ、いわゆる 神絵師 とかの作品を見ると、そりゃあ意欲もなくなるものである。
無くなるが、ずっとくすぶってばかり居て行動しないのが筆者である。

創作は思考の道具であり、伝達手段でもある

この章のタイトルの元ネタは、川崎昌平氏の「労働者のための漫画の描き方教室」の50ページの、

表現とは思考のための道具である

その一文ほぼそのままである。

後は気が向いた時に度々読む、Eric S.Laymond 氏の「ハッカーになろう」だろうか。

母語できちんと文が書けるようになること（わたしが知っている最高の連中を含め、ハッカーの驚くほど多くは物書きとしても有能です）。

SF を読むこと。SF 大会に参加すること（ハッカーやハッカーの卵たちに出会ういい方法です）。

ハッカーになろうを引用はしたが、私はハッカーではない。いいとこコーダーである。

また、もっと「まんがそのものの描き方」に関しては、ありがたいことに
KADOKAWAのComic Walkerで「まんがでわかるまんがの描き方」
という漫画が公開されているので、これの10話くらいを読むと書ける気分になれる。

「まんがでわかるまんがの描き方」では、まず 字コンテ の書き方から解説しているの
で、個人的にはかなり良いと感じた。

さらに、「物語そのものの書き方」というところであれば、
読書猿氏のブログの創作の道具箱
を眺めてみると良いだろう。

これらの資料を並べた理由としては、マンガに限らず物語は「説明できてなんぼ」のものであり、また物語のテーマ、テーゼ、アンチテーゼ的なものがある程度持っているものであれば、そのテーマやテーゼそのものについて直接語るより物語にした方が、読み手は案外物語の著者自身に対しての反感を比較的抱かずに著者の訴えたい主張を聞き入れ易いと思っている。

また、小説やマンガだと比較的書き手自身が考えをまとめながら描くことがしやすい。いや、筆者がそこまでものを考えて時たま創作活動しているかというとそうでもないし、ましてや熟練した個人のアニメーターやゲーム作家なら、絵コンテやゲームデザインしている時点でまとめているとは思うが。

最後にあえてマンガを薦める理由としては「労働者のための漫画の描き方教室」にも書かれていると記憶しているが、やはり絵図の方が肩肘張らずに読みやすい。もっとも、これは今日までのマンガという表現媒体に対する印象が、比較的「幼稚」と取られている節もあるため、もしかすると数十年後には書籍のマンガを読むことさえ知的な行為になるかもしれないし、マンガの読み方が分からないという青少年もいるとかいないとか噂に聞いた
りする。

と書くと、「オブラートに包みつつも主張をしっかり使える媒体」としては動画や演劇になるのかもしれないが、今の筆者には動画を描く労力が途方に思えるので、とりあえずマンガ。

Blender やUnity やUnreal Engine,Godot Engine でも Armory Engine でもUPBGE でも、Synfig Studio やOpenToonz
でも何でも良いが、それらの使い方を一つでも熟知している方なら、筆者のこんな御託に付き合っている暇もなく、とっくに動画やゲームの制作に取り掛かっているだろうけど。

雇われプログラマ・ソフトウェアエンジニアよ、

ここまで長ったらしく書いたが、筆者が述べたいことは以下。

妄想してくれ

病気による妄想ではなく。楽観的で漠然とした希望を妄想すると、割と幸せだと筆者は思
う。

筆を握ってくれ

そこでせっかくなのでその妄想を共有していただきたく、筆を握っていただきたい。
できるならばそういう希望を抱くまでの過程になるような物語を添えて。

そして書いた（描いた）ものを共有するかしないかは任せる。でも共有していただいたほうが、筆者限らず、誰かの考え方の幅が広がるきっかけになると思う。

とはいえ、肌感覚や感性の違いという「解せん」という感情が発生することもままあると思うので、そのときは「解せん」で片付けてしまって良い。筆者も「口では大層な事を宣いているが、自身は全くそれに準じて行動していない」やつに対しては、「解せん」で絶交したし。

以上が「論文・弁論に限らない自己主張の提案」という弁論である。

オチ

と戯けてみたものの、私は特別これと言えた作品は何も出さずに、人間年齢 30 歳になるので、筆者を反面教師として蔑み、この文章を読んだ方には創作活動に励んでいただきたい。御託を並べるのが大好きな下等知的生命体なもので。

参考資料・影響を受けた資料

脚注

1 自由ソフトウェアとは？ - gnu.org

【禅Do】利用しているライブラリについて

2019-06-19T23:27:01+09:00

導入したライブラリについて

とりあえず当時、Carthageの情報が結構出ていて使いやすそうだったので
基本的にCarthageを利用してインストールする方針でやっていた。
その中で対応していないものはCocoaPodsを利用するか、直接ソースを入れる形にした。

Carthageで入れたもの

SwiftDate
- リマインド機能の日付操作の為に導入
Bond
- リアクティブプログラミング的なものを使ってみたかった為
- 全体設計の見通しの良さ向上の為など
Eureka
- 設定画面でリスト型テーブルやForm作成を簡単にするための導入
Log
- 開発用途。デバッグのしやすさ向上の為
Quick
- 開発用途。テストコードを書く為（なおちゃんとテストコード書いてない模様）
Nimble
- 開発用途。テストコードを書く為（なおちゃんとテストコード書いてない模様）

CocoaPodsで入れたもの

firebase-ios-sdk
- （今もかもだけど）当時モバイルのアナリティクスとしてイケてる感じだった為導入
- ユーザ動向を知るため

直接入れたもの

FontAwesome
- 各種アイコンに利用
DatePickerCell
- 設定画面でのCell操作の為に導入

導入ライブラリのアップデート

とりあえず当然ビルドが通らなくなってため、各ライブラリの最新版を利用するように
Cartfileを書き換えてアップデートしてみた。
ただそもそも、Carthageの使い方を忘れていたので、思い出すために下記記事などを参考にした。

Carthage について
 Carthage Tutorial: Getting Started

さらに元々、Carthageディレクトリ以下のBuild/Checkoutsもgit管理下においていたが、
ライブラリアップデートを何回も試してる時に、いちいち削除が面倒になったのと
下記の記事を読んだので、git管理化から外すことにした。

CocoaPods・Carthageでインストールした成果物はバージョン管理に含めるべきか？

アップデート方法

利用しているライブラリのうちほとんどは、Swift3へのアップデート対応等がされていたが
Logライブラリだけはメンテが止まっていたので、forkして対応することにした。
（代替のものを探したが方が良いが、とりあえずビルドを通すのが第一目標なのでそのまま利用）

直接ソースを入れるタイプのものも、Carthage対応されるようになっていたので
Carthageを利用してインストールする方式に変更した。

メンテナンスされているライブラリはバージョン指定を外して
最新版をインストールするようにした。

下記はSwiftのバージョンを3にして carthage update --platform iOS が
問題なく実行できるようになった時点でのCartfile。

# Use libraries
github "malcommac/SwiftDate"
github "SwiftBond/Bond"
github "xmartlabs/Eureka"
github "Quick/Quick"
github "Quick/Nimble"
github "thii/FontAwesome.swift"
github "DylanVann/DatePickerCell" ~> 1.0

# Own repos.
github "stlwolf/Log"

備考

carthageでのインストールが成功するところまで行き、Xcode上でライブラリを
利用しているコードでErrorになってる箇所を修正することができる状態にはなった。
Bondライブラリがアプリに入れた時期から大きな変更が入っているので、利用方法を含めて
再度使い方を調べないと最新版のコードを利用できそうにないことが判明。（ReactiveKitに組み込まれてる？）
公式Docと下記あたりを参考に別途キャッチアップする。
Bond Tutorial: Bindings in Swift | raywenderlich.com
Bond, SwiftBondを使ってみよう！ - Takahiro Octopress Blog

Dockerでdev.toのローカル環境構築を試した（途中止め）

2018-08-25T22:49:40+09:00

先日dev.toがGitHubに公開され、オープンソース化されました。ローカル環境の構築方法も公開されていたため、実際に試してみました。あまりPCを汚したくないので今回はdocker-composeを利用して、Dockerで環境を構築してみました。

設定

docker-compose.yml

gemとDBのデータはvolumeに保存して永続化
DockerHubにあったyarnが入っているrubyの適当なDockerイメージを使った
Algolia関連の環境変数は適当に入れておく

version: '2'
volumes:
  bundle:
    driver: local
  db_data:
    driver: local
services:
  db:
    image: postgres
    volumes:
      - db_data:/var/lib/postgresql/data
    expose:
      - 5432
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
  app:
    image: electrotumbao/ruby-yarn:2.5.1
    volumes:
      - bundle:/usr/local/bundle
      - .:/app
    working_dir: /app
    ports:
      - 3000:3000
    depends_on:
      - db
    environment:
      RAILS_ENV: development
      GITHUB_KEY: aaaa
      GITHUB_SECRET: bbbb
      ALGOLIASEARCH_APPLICATION_ID: 1111
      ALGOLIASEARCH_SEARCH_ONLY_KEY: awefawf
      ALGOLIASEARCH_API_KEY: awefawfe
    tty: true
    stdin_open: true

database.yml

うまいやり方があるのかちょっと分からなかったので、とりあえず直接書き換えておきます。セットアップ時にtestもマイグレーションしているっぽいのでtestも同様の設定をしておく必要があります。

host: db
username: postgres
password: postgres

手順

Dockerコンテナを起動

docker-composeしてDockerコンテナを起動し、中に入ります。

docker-compose up -d
docker-compose exec app bash

色々インストール

gem install bundler
gem install foreman
bundle install
bin/yarn
bin/setup

Algoliaは有料なので、設定に適当な値を入れているのですが、bin/setupの際のSeedの実行でエラーになるっぽいです。ただ、マイグレーションは完了するっぽいので、無視しています。

起動

とりあえずここまでで一応最低限の設定は一通り行っていると思いますので、試しに起動してみます。専用の起動スクリプトがあるようなのでそれを使います。

bin/startup

動いたっぽいのでlocalhost:3000にアクセスしてみます。

なんか変な画面が出てきました。

良いニュースと悪いニュースがあるんだ。悪いニュースはあんたがオフラインってことさ。いいニュースはここでは絵を書けるんだぜ

というよく分からないメッセージが出てきます。原因はよく分からないのですが、どうもserviceworkerあたりが関係あるかも知れません。

仕方がないので、とりあえずはrailsのサーバーで起動してみます。

bin/rails s

初回は表示までに時間がかかる（？）ようですが一応dev.toっぽい画面が表示されるっぽいです。

まとめ

とりあえずなんとなくdev.toの画面が表示されるところまで試してみました。是非色々な方法でローカル環境を構築してdev.toのcontributeまで試してみてください！