はてなキーワード: IDEとは
べつにおどろくことでもなんでもないけど、honkitできた!
Node.jsがらみのツールらしい。これってのもはじめての経験だ。Node.jsとはjsの開発環境のこと?なんじゃ?IDE?
ディレクトリーに適当にマークダウンファイルやjsonファイルをおいておけば、HP作成してくれた。htmlタグをベタ打ちするのも、いやだった。だからよかった。
さいきん、ベタ打ちすることないし、といっていちいちpandocとかで変換するのもめんどうだし・・・よかった。
いまのところ、git repoでもなんでもないフォルダーにマークダウンファイルなどをおいて、honkitでウェブファイル作成してから
そいつをエイヤーっとgit repoに動かして、git push でリモートにもっていって、さらにgithub pagesでHPにしているけど・・これって
今でこそWindowsでも全く問題なく開発できるけど、ちょっと前は「Macのが開発体験が良い」と言われていた。
具体的には2011~2015年あたり。
2013年のころ、俺はWindowsで開発していた。WSL2なんてものは当たり前に存在しない時代だ。
たとえばC言語を使いたい場合、MinGWとMSYSを使ってこんなかんじで必要なものにチェックマークをしてインストールしていた。
まちがえた。俺が使っていたのはCygwinだ。こんなかんじでインストールする。
「パスを通す」とか言われていた時代だ。今ではインストーラがほとんどやってくれる。
Windowsのコマンドプロンプトがアホほど役に立たないので、msysCygwinのコンソールを使うのだ。
Pythonのインストールにもパスを通していた時代だった。当時はまだ2系が主流で、卒論を書く際、大学の教授から「3系は使ってもいいけど、俺は知らないからサポートできない」と言われた。
Scipyはインストールしなければ使えなかったので、「python scipy インストール」で検索して出てきた記事を参考にしてインストールしていた。これがまたエラーの連続だった。
プログラムを開発するエディタも、vim、emacsがまず候補に上がった。どちらも癖のあるエディタなので、そういうのが嫌な人はサクラエディタが推奨されていた。そして少しして登場するAtomに感動したのだ。今ではあたりまえのようにVSCodeがある。
ちなみに俺はPythonの開発ではIDLEというのを使っていた。知ってる?こんなの。
そんなWindowsユーザーを少し煽るような(Winユーザが自虐するような)、「プログラミングするならMac」という風潮があったと記憶している。そこから「どうやらMacはUnix系で、コンソール操作が簡単らしい」「文字がきれい」「Windowsでは定期実行するためのcronすらないが、Macにはある」「xcodeというのがあるからめちゃくちゃプログラミングがラクらしい」みたいなイメージがあった。
今ではWindowsも随分便利になったし、IDEやインストーラがなんでもしてくれるようになった。今では結論、「どっちでも好きなほうを使えばいい」という良い環境になった。
非常に長文なので誰も読まないかもしれないが、読んでいただければ幸い。
日本人の宗教批判は主にオウム神理教や創価学会あたりから根深くなったと自分は思っている。とにもかくにも「宗教はやばい」となり、それが「宗教的なものはやばい」となっているのではないか。たしかに新興宗教団体はやばかった。最近でも、自民党から膿となって出てきた旧統一教会の問題がある。
日本人全体で、なんとなく「宗教はやばい」というゆるやかな共通認識があると思う。
そこから「宗教について熱心に語る者は、なんとなく、やばい」とされていると思う。ごく少数の人間だけが宗教について深く調べる。多くは、ミイラ取りがミイラになることを恐れているとか、宗教的な人間とみなされることを怖がっていたり、単に無関心な可能性もある。
ほとんどの人は、まずその「ヤバい」「うさんくさい」「拝金主義」という外から見える性質に嫌悪感を感じているはずだ。実際に、古来から権力・権威・金銭などと結びつきが強いように思う。多くの人々に害を為すものは、それが宗教だろうがなんであろうが、どういう形をとっていようと敵対される。宗教に対するネガティブな意見は、おおよそこの表面に出てきた宗教のネガティブな部分についてのものが多いと思われる。
また「人型の何か偉そうにした超常の力を持ったジジイ」を幻視して「そんなやつがこの世界作ったわけないだろ」と直感的に思うのではないか。
宗教的なものがやばいの1つの例でいえば、ガチのドルオタはキモいというものがある。キモいというのは比喩的表現で、ドルオタクラスタの方には申し訳ない表現だが、周りからは理解不能なのである。アイドルという神を信仰することで「生きがい」となして自分の人生を全うしていく。しかしひとたびその信仰の前提が破壊されれば、一瞬にして生きがいを喪失する。
アイドルの推し活は「きわめて宗教的だ」と半ば冗談めいて表現されることが多いが、比喩でなくそのまま宗教といっても過言ではない。仮に江戸時代に今のアイドルの状態を維持可能な状態で放り込めることができるとすれば、瞬く間に江戸幕府を牛耳ることができるだろう。実際BTS外交などと言われるほどアイドルは脅威的な潜在能力を持っている。一向宗など目ではない。江戸の民たちはアイドルの存在を知覚することで、それに畏怖し、夢を見ることができ、人生に生きる意味を見出しやすくなることだろう。本居宣長も、古事記伝にて「それはさておいても◯◯ちゃんのかわゆしこと尊し」などと書くかもしれない。知らんけど。
宗教のはじまりはアニミズムだという。何か神聖視せざるを得ないものを発見しそれに畏怖し感動することで、その圧倒的な偉大さを見て、人はそれを「神」と名付けたようだ。
日本では現状「科学信仰」と「常識信仰」が主流であると思う(これは自分の主観による)。「科学的な権威がありさえすれば信用する」だとか「よく知れ渡っているから信用する」といったものだ。「長いものには巻かれろ」という日和見主義的な発想がそこにあるように見える。
そもそも「信じる」とは「実際に本当にあるかどうかわからないが『ある』と信じる」ことにある。
自分には本当にあるかどうかよくわからないものを『本当にある』と思い込むことを信じるという。そういう行為には、根拠など無いのではないか。少し古いが「アイドルはうんちしない」などがそうだ。
宗教が必要かどうかは置いておいて、その発生過程や宗教が果たしてきた役割は、歴史を学習すれば誰でもその関連性には嫌でも気付くだろう(重要性は別かもしれないが)。人は「たかが宗教ごとき」で人を殺し合い、憎み恨み、人生を捧げたり、幸せになったり、正しく生きようと努力したり、救われてきた。さまざまな血を流してきたのであった。これは事実である。現在の今の自分にとって宗教は全然必要でないと感じていたとしても、その自分が存在する羽目になった基盤に宗教がある。一体全体どうしてこんなものが人類の中で大きな役目を持つようになったのか。
真に必要でないのであれば、なぜこの世から抹消できないのか。たとえばガラケーは抹消されつつある。必要でなくなったからだ。しかし宗教はどうか。消せども消せども名を変えて復活しているように思う。
科学的であると自負する人であっても、古来から続く伝統的な宗教っぽいものをなんとなく忌避していて、その拝金主義的傾向や宗教の政治的利用による人間支配を見て、なんとなく嫌悪しているのではないか。
また「宗教が必要かどうか」を論じるとき、「実際になくせるかどうか」のその現実性について論じられることは少ない。宗教がなくなれば代わりのものが出てくるのみである。名を変えたそれが絶対視される。
実際にとりあえず「宗教は必要ないもの」と考えて、この世から排除することにしてみよう。つまりそれは逆に言えば「信教の自由」の剥奪である。仏教を信じてはならない、キリスト教を信じてはならないとされる。
ありとあらゆる宗教的なものは不要なので排除されなければならないとする。しかし、必要か、不要か。それは誰にとって必要なのか、誰にとって不要なのか。
宗教と宗教でないものについて、どこで、誰が、どのように、なんの権限で線を引くのか。これはもしかすると権力闘争の始まりかもしれない。受容するか・弾圧するかのどちらかを、ある人間の主観で決めることができるということほど恐ろしいものはない。異端審問のラベリング(【十分科学的でない】というラベル)を受けて生きなければいけない世の中は厳しいものになるだろう。反ワクチン派・反知性主義者が実際にそうした世の中を生きている。われわれから見れば彼らは狂っているが、彼らから見ればわれわれが狂っているのである。
宗教と科学はなんの根拠もなく二項対立されがちだが、これは一神教的な態度ではないだろうか。
つまり科学的であればあるほど宗教的でなくなるはずだという根拠のない「思い込み」があるのかもしれない。
いったいなぜ、科学的であることが正しいのだろうか。いったいなぜ、論理的であることが正しいのだろうか。これは唯物論的な立場である。いったんそういうことにしているという、あくまで仮説である。そのように考えるとうまくいっているだけなのではないか。
そして、自分にとって宗教が必要ないからといって、他人にとっても同様に必要ないとは限らない。つまり全体としては「まだ必要」というのが答えになると思う。
それから自分は、ロジカルシンキングや科学最強説を強硬に主張してその他の考え方を排除しがちな陰キャはあまり好きではない(自分はロジカルシンキングそのものや科学的思考は好きだが、論理的であることが正しいことを信じることは論理的ではない、という前提があると思うからだ)。
彼らは科学や論理というアカデミックな権威のおこぼれを欲しており、いわば虎の威を借る狐のように見える。そうした人間は、自分よりも科学的で自分よりも論理的な人間が宗教的なものを崇拝しているのを目の当たりにしたとき、考え方を転向するかもしれない。これを改宗(conversion)というのだろう。
Visual Studio Code等さまざまなIDEに組み込んでコマンド操作できるテキストエディタがある。これはVimと呼ばれ、世の中で広く親しまれている。入門はやや難しいが、Must-Haveでおすすめである。これは宗教以上に必要である。
もちろんあなたはVimを導入しないという選択をとることもできる。
こう言うと自分は旧来の宗教観を引きずっているように思われるかもしれないが、一方で自分は古来から続いておりただの慣習となっていて合理的ではない規則を、ただ自分の強権を保とうとせんがために信じている老害もまた好きではない。彼らは自分の保身を考え、自らの世界観の安定させ、外に目を向けない人間である。生臭坊主と言われる。
自分は、そうした既製品の宗教や、新興宗教の教祖というただの詐欺師をそのまま信じてしまう人は愚かだと思うが、そういうことも含めて現実でありなぜそういった事象がでてきてしまうのか、なぜ彼らはそれに縋りつくはめになったのかを単に否定することは科学的ではないと思う。それは現実を観察できていない。少なくとも彼らにとって、彼らを救ってくれるのは科学ではなかったということなのだろう。
宗教はおもしろい。とりわけ理系で哲学や文学や詩や宗教やヒトや精神や心というものから縁遠かった者ほど、大人になってから初めて知ることで、そのおもしろさに気付きやすいかもしれない。
コードの重複があるわけでもない状況で、コードを関数ごとに分離するメリットデメリットを知りたいという話ですよね。
コードの重複がある場合に関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。
画面に収まらないサイズのコードは複数の関数に分割するのが一般的だとは思います。
理由は元増田も書かれている通り、長いと理解の限度を超えるからです。
コードは意味があるまとまりで短ければ短いほど理解がしやすいと思います。
グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さらに理解がしやすいです。
また、関数に分けておけば、関数が仕様通りに動くかの確認するユニットテストも簡単に書けます。
ユニットテストでは関数がさらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります。
分割して、複数の関数を呼び出すようにすることのデメリットは、
下手糞が切り分けるとなんでそういう切り分けになったかわからないところで切り分けられてかえって可読性が損なわれるとか、
関数の機能が拡張してより多く・あるいは少なくの情報が必要な時に関数インタフェースの変更が必要になることとか、
関数を置いているファイル内の場所を変えたときにバージョン管理システムが追っかけてくれないことがあるとか
くらいでしょうか。
いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います。
まず、関数の名前をやっている工程を表すものにすることですね。
「データの取り込み」 とか 「データの突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。
また、関数が何をしてくれるのかも関数のコメントとしてつけておくとよいと思います。
例えば、
filename引数で指定されたファイルからデータを取り込み、JSONフォーマットで返す
返値: JSONフォーマットされた取り込まれたデータ。例: [{'employee name': '山田 太郎', 'employee id': 1}]
例外: filenameを開けない場合はFileOpenError、JSONにコンバートできなかった場合はConvertError
みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。
あと、コードを連続で読みたい場合、ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います。
これはどういう意味でしょうか?同じものを表すのに関数ごとに別の変数名を付けているとか?
もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか?
ある関数のローカル変数が他の関数のローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当な名前が付けられるイメージです。
今時のプログラミング言語なら変数のスコープが関数の中にとどまるような書き方ができると思うのですが。
関数インタフェースを定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。
そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。
参考までに。
https://qiita.com/app_js/items/a78e0605af702b155efc
この記事読んだ。
Paizaの対応の良し悪しやこの人の考えや不満については今回は触れない。
一人のITエンジニア採用担当者、また同時に一人のITエンジニアとして生成系AIに対してどう触れるべきか書いておく。
まず、業務で生成系AIを利用するのは会社のルールの範囲で好きにやれば良いと思う。
問題は転職のフェーズであり、ここでは能力をチェックされているわけだから、生成系AIの回答でコーディングテスト通過です、となるわけがない。
ソフトウェア開発は複雑であり、AIは間違った回答や遠回りな回答もするわけだから、生成系AIを使うにしても結局真偽を確かめられる能力は必要だよね。
コーディングテストで生成系AIを使うというのは「私はそのような最低限の考える力も有りません」と言っているようなものなので、企業側がほしい人材とは言えない。
最近のコーディングテストサービスでは入力内容を記録しているのでコピペしたかどうかは分かる。
なので生成系AIで回答しているような場合は企業側はある程度検知できる。
もちろん誤検知もありえる。サービス(Web)上ではなくIDEなどで回答を作って貼り付けることもあるだろう。
そのため、企業はコーディングテスト通過後の面接で回答に対して深掘りすることが多い。
生成系AI回答で何も考えていない人はここで脱落する。
企業によってはコーディングテストサービスではなくホワイトボードなどでライブコーディングさせる場合もあり、そもそも生成系AIが使えないこともある。
なんというか、ネタにしか見えないんだけど。本当はできる奴がバカのフリして書いているみたいな感じしかしない。
むしろ、大学から情報系の勉強を開始して、中学ぐらいからコードを書いていましたみたいな人たちをスパッと抜き去っていく人が世の中にいるのは知っている。
どこの大学か知らんけど、大学でも大抵は実習の授業があるはずで、そこでプログラムを書くものだと思う。
10年以上前にTAしていた時にすでに学生にIDE使わせていたが、今時IDE無しでプログラミング学習させるなんて冗談だろと思う。
海外の大学などがYouTubeで講義を公開していたり、コーディングを教えるようなYouTubeチャンネルもあるから別に本で勉強する必要はないと思う。
元増田がそういうことを知らないとも思えないので、正直ネタにしか見えないなと思う。
プログラミングの勉強は全部の意味が分からなくてもとりあえず写経して、そのうちに全部の意味が分かるみたいなところがあるから、わからないことはしたくない!という人には向いてないかもな。
あー、うん、まああれはだいたいは正しい
そのかわり実行時には何も決まってなくて本質的にぐちゃぐちゃしてるし、「普通」の言語なら当たり前のようにできる静的なIDEサポートの提供も弱くなる(実行しないとわかんないんだから仕方ない)
Rubyはなんでもできる!という万能感はプログラミング人生においてなかなか楽しいのであなたが35歳以下ならRubyの履修を強くお勧めする
36歳以上の人に無理には勧めない
あと、3年くらいドはまりしたあとに「いや規模が大きくなるとRuby不便だな…Kotlinとかよくねえ…?」みたいに覚醒して浮気してそれっきりになったりするので進路については心配しなくてもいい
0か100かで話すなら全くその通りで、コーダーよりある種のコンサルの方が先に0になる気はする。
ただ、AIの影響でコンサルが80ぐらいになったタイミングではコーダーが20ぐらいになってるんじゃないかなー。そして元々の絶対数はコーダーの方が圧倒的に多いので影響を受ける人数も絶大になるのでは
ChatGPT的なやつが本格的にIDEに組み込まれたらコーダーの仕事量減る→人減らすになるでしょきっと
ちなみに今のコンサル業界レイオフはAIの影響じゃないぞ。例えばおまえのプロジェクトがうまく行かないときにChatGPTに相談して解決する(=PMOやるコンサルがいらない)か試してみたらいい。
ChatGPT が脚光を浴びて AI の台頭が本格的になってきている。
1年というスパンでは変わらないが5年後の世界は様変わりしてそうだ。
ChatGPT は素晴らしい。Google Home っぽい LP を作らせてみたらものの5分程度のやり取りでできてしまった。
これからのプロダクトマネージャー・プロダクトオーナー(PO)がこれを活用していくのは間違いない。
自分がPOならこれを使って自分でできることがないかを探ってみるだろう。
とはいえ Rails のアプリで作る複雑なものは大変なはずだ。
できなくはないが、時間はかかる。
「Twitterクローンを Rails で作りたいです。手順を1から教えてください。OSはMacです。」
試しに質問してみたところ、rbenv のインストールから devise の導入から本当に1から手順を書いてくれている。
これで作ってしまうのはスマホだけで動画を作成するティーンネージャーYoutuberのようだ。
プロのデザイナがなくならないけど、プロのデザイナがいなくても動画は作れる。
これはプロのデザイナへの要求レベルが上がる、と言う意味でもある。
さらに直接対話して要求を伝えることで、細かく自分で調整しなくてもいいようにやってくれること。
ソースコード全体を知識にしたIDEができたら、コードの変更の難易度も間違いなく下がる。
プロンプトを作る能力、と言うのはあるかもしれないが、いずれ誰にでもできる仕事になるかもしれない。
ChatGPTの進化を経てその先に残るプログラマーの仕事とは何だろうか。
こうして全ての知的労働がなくなっていったら、最終的には社会的課題しか残らないのではないか。
リストはありきたりだけど説明がありきたりじゃなくて凄いと思う
この増田の本業は一体なんなんだ、ゲーム系IDEとかDBとか挙げてるところを見るとプログラミングから絵や音楽まで自己完結できるゲームクリエイターとかディレクターかな?
いやわかる、MS OfficeとかAdobeは業界標準だしファイル互換でインポートとかも楽だ。
ただまぁその万人へ必須か?と言われたら圧倒的にそれが必須じゃない仕事をしている人のほうが多い。
何なら仕事じゃなくて趣味レベルであるならばなおさらMS OfficeとかAdobeとか業界標準ソフトウェアじゃなくても良くなっちゃう。
ということで、ありきたりなシェアウェア代替オープンソースソフトウェアのリストを作ってみた。
ド定番中のド定番、オープンソースのオフィススイートだ。
MS Officeじゃなくて良い人はLibreofficeかGoogleのクラウドのヤツを使ってる。
やはり主に使われるのはワープロソフトのWriterと表計算ソフトのCalcとプレゼンテーションソフトのImpressだが、MS Accessの代替として挙げられるBaseは厳密な意味で代替とはならないためMS Accessの代替を無料でゲットしてやろうと考える人が陥りがちの罠だ。
まぁただデータベースのフロントエンドソフトとしてBaseはそこそこ使えるので、MS Accessの代替として捉えるのではなく別種のデータベースフロントエンドソフトとして割り切れば想定されることの大半ができる。
MS Visioの代替としてDrawも挙げられがちだがMS Accessの場合と同様にDrawもVisioの厳密な代替とはならないので注意が必要だ。
Adobe Illastratorの代替として挙げられがちなオープンソースのベクターグラフィックスソフトウェア。
高機能なのだがIllastratorと比較すると恐ろしいほど使いにくいUIを持っており、折角の高機能へアクセスするにはどうしたら良いのかわからないと挫折する人が多く出る。いやなんでホントこんなUIなんだ。
ただ、諦めずクソUIに付き合っていると不思議なもので人間は慣れてしまい結構自由度高くベクターグラフィックスを生成できるようになる。
Adobe Illastratorには無い長所としてSVG規格へ厳密に従うという方針で開発されているため、Illastratorで生成したSVGをWebでそのまま使うとWebブラウザで謎の描画バグにWeb屋は悩まされるがInkscapeではそれが無い。描画バグが起きるとき製作者が間違った設定を行っているか、Webブラウザ側が使っている設定に未対応な場合がほとんど。
将来的にサポートする気はあるらしいが現状はアニメーションSVGに弱いのも残念でならない。どうしてもアニメーションSVGをやりたいのであればInkscapeで生成された静止画SVGをアニメーションSVG化することを想定しているaniGenというWebベースのエディタがあるので調べてみると良い。
Adobe Photoshopの代替として挙げられがちだが、元来Web用の画像を製作するためのラスターグラフィックスソフトウェアなのでRAW現像や写真を加工するためのソフトじゃないが、本家すらその辺のことを忘れたふりをしている。
画像編集や加工で求められる基本的な機能はほぼ網羅されているが、RAW現像に関しては標準状態のままではできず、最近のAdobeが搭載している人工知能を用いた機能もないのでクラシカルなラスターグラフィックスソフトウェアと表現することもできる。
GIMPとInkscapeが使えると大半の画像製作は何とかなってしまうため一部の情報技術者寄りのギークはPhotoshopやIllastratorは触ったこともなく使えないがGIMPとInkscapeは困らない程度には扱えるというデザイナーがツッコミ入れそうなおかしなスキルセットになっていることがある。
Adobe Lightroomの代替として挙げられがちなオープンソースのRAW現像ソフトウェア。
実はdcrawというRAW現像のためのオープンソースのライブラリのフロントエンドであり、GIMPでRAW現像するために活用されるUFrawも同様にdcrawのフロントエンドであるため中身は同じだったりする。オープンソースのRAW現像ソフトウェアはdcraw使いがち。
オープンソースソフトウェアでRAW現像を賄っている人はGIMPでUFrawを活用してRAW現像するよりもUI的に使いやすいのでRaw TherapeeでRAW現像でTIFFを出力しGIMPで微調整するような使い方をしている人が多い。
オープンソースの2D CADで以前はQcadと呼ばれていた。
一部の読者はJw_cadのJWWファイルを扱うことが可能という特徴を持っているというだけで興味を惹かれてしまうのではないか。
Jw_cadとは違ってWindowsやmacOS、各種Linuxディストリビューションで動くので2D CADデータをネット上の友人知人などとやり取りしたいときに向くんじゃなかろうか?ニコニコ技術部的な遊びとか、最近流行りのルール無用JCJCタイムアタックとかで。
オープンソースの3D CADで、近年は3Dプリンターあたりの需要でよく目にするようになった。
Autodesk AutoCADやFusion 360、Dassault Systèmes SolidWorksよりも草の根では広まっており日本語でのハウツー記事もオープンソースソフトウェアとしては比較的多い印象。
シミュレーション機能はシェアウェアと比較すると弱い傾向があるものの草の根でそこまで必要か?と言われたら悩む。無料でシミュレーションやりたいならOpenFOAMにでも流し込め。
オープンソースのお絵描きに特化したラスターグラフィックスソフトウェア。
歴史的経緯ではLinux界隈でのGUIツールキットの2大巨塔にGTKとQtがあり、GTKはGIMPを作り上げるために生まれたこともありGTK側には高度なラスターグラフィックスソフトウェアが存在していたがQt側には存在していなかった。そこでGIMPの対抗としてQtを用いたKritaの開発が進められたが次第にGIMP的な画像編集ソフトウェアよりもお絵描きに特化していき現在のような性格を帯びるようになった。
SYSTEMAX ペイントツールSAIやセルシス CLIP STUDIO PAINTからの影響が強く現れており、オープンソース界隈のSAIやクリスタなどと呼ばれることがある。クリスタがそうであるようにスマートデバイスへの対応も計られAndorid OS版やChrome OS版が存在する。
ただ日本の需要を敏感に拾えるクリスタなどと比較して漫画作成機能に関してKritaは弱いと言われることがあるものの、GIMPと同様に無料とは思えない機能が充実しているのもまた事実である。
オープンソースの3DCGアニメーションソフトウェアで、非常に多機能のため何故かAdobe After Effectsの代替として挙げられることもある。
YoutubeがBlenderのYoutubeチャンネルへ広告を載せろと迫ってBlender公式がそれを拒否してYoutubeから撤退したり、庵野秀明が率いる株式会社カラーが出資したことなどオープンソース界隈でも異彩な存在感を放っており日本国内でも非常に注目されているプロジェクトだ。
ただ、初期状態では独特なUIによる使い勝手が非常に悪くユーザーが自分で使いやすい配置を模索する必要があったりタイムラインが使いにくかったりと何故オープンソースソフトウェアはUIがクソになりがちなのか?という問題にぶち当たる。
オープンソースの2DG/3DCG兼用プログラミングIDE。つまりはUnityとかみたいなやつ。
MIT Licenseでロイヤリティーフリー、開発言語はC#もしくはC++、そしてPythonライクなGDScriptで、Unityみたいにマウスでポチポチしてオブジェクトへ色んな設定を決められるので「Unityみたいのでゲーム作りたいけど運良くヒットしたときにライセンス料がなぁ」と懸念している人に役立つ。
ちなみにWiiとニンテンドーDS用向けにリリースされたSEGAゲームタイトルのソニックカラーズのSwitchやPS4などのマルチプラットフォーム移植版ソニックカラーズ アルティメットはGodotを用いて移植されているので商用でも耐えうることはSEGAが証明している。あのSEGAがソニックでだ。
オープンソースな動画編集ソフトウェア。
様々な部分で動画ライブラリのFFmpegへ依存しているためFFmepgのフロントエンドソフトとしての性格も持つ。
この手の無料の動画編集ソフトは国内だとAviUtlや近年ではBlackmagic Design DaVinci Resolveが人気だけれど、海外のオープンソース界隈ではShotcutは比較的知名度が高い。
カラーグレーディングに関して不足のない機能を有しているので高度なトランジションを用いるというよりも色を追い込むような使い方が合っているだろう。
ていうかFFmpegのフロントエンドなのでFFmpegができることは理論上なんでもできる(理論上なので追加でコマンドを叩く必要があったりするけどね)。
オープンソースのレコーディングソフトウェア。旧名称はAudacityと言われるとご存じの方も多いハズ。プライバシー問題でAudacityからプロジェクトが分岐されTenacityとして再出発することとなった。
旧Audacityは開発の主な拠点がロシアを中心に行われていたという経緯があり、現在のウクライナ-ロシア戦争へ至る前の影響からか個人情報の収集をロシア企業が行うと発表され、それに反発したユーザーらによってプロジェクトが分岐しTenacityプロジェクトが立ち上がった。
Audacity自体はVSTプラグインが動作するなど非常に高機能なレコーディングソフトウェアであったがウクライナ-ロシアの騒動に巻き込まれたと言った感じだ。
Audacityから分岐したTenacityもそのまま高機能なレコーディングソフトウェアなのでこれからはTenacityを使ったほうが色々面倒が少ないだろう。
ProToolsの代替として挙げられがちなオープンソースのDAW。非常に高機能でDAWとして求められることの大半ができるものの、これもまた通例通り最近流行りの人工知能を用いた云々かんぬんは標準状態だとできない。
Ardourプロジェクトの立ち上げをし主要開発者であるポール・デービス氏はJACK Audio Connection Kitのプロジェクトの立ち上げをし主要開発者であるという事実を伝えると驚く人がいるかも知れない。LinuxとGitのリーナス・トーバルズ的な文脈だ。
オープンソース界のFL Studioと呼ばれることもあるDAW。ステップシーケンサーを中心に作曲するタイプのDAWで電子音楽が得意。LMMSという名称はLinux Multi Media Studioの略でLinuxに端を発してマルチプラットフォーム展開をしたDAW。
オープンソースのDAWにしては珍しく初期状態から多数のソフトウェアシンセサイザープラグインが用意されておりインストールした時点で遊び始めることができるものの、オープンソースの例に漏れずクソUIを持っており使いにくい。GIMPやBlenderもそうだが1990年代後半〜2000年代前半あたりに流行したMDI(Multiple Document Interface)を未だに引きずっているためクソUIになりがちなのだ。
ググると日本国内にも意外とユーザーは居て、DTMやりたいけど初期投資は低く抑えたいみたいなユーザーが選んでいる模様。そういう需要ならLMMSの他に基本無料で全機能が使えて一部のプリセットが有料のVitalっていうソフトウェアシンセサイザーも導入しておくと延々遊べるよ。
オープンソースなWebブラウザとして非常に有名な存在。
Google率いるChromium系Webブラウザに近年物凄く押されているものの独禁法を回避するためGoogleはMozillaへ出資しているという歪な構造を持つ。
Mozillaの運営が下手すぎて資金をドブに捨てることを繰り返しているためGekkoレンダリングエンジンに未来があるのかと一部の識者から不安がられている。
Firefoxは使いやすいのか?と言われたら、それはもう好みの問題としか返せないのだがカスタマイズ性は非常に高い。
増田を全削除するのであればPower Automation DesktopかSelenium IDEあたりでも使えば可能ですが、中にはブクマを集めた珠玉の増田やブクマは付かなくても割と気に入ってる増田もあるので全削除はしたくありませんでした。
Masuda Deleter
https://github.com/oribeolive/masuda-deleter/
Masuda DeleterはDockerコンテナに環境を作って動くのでDockerが必要です。
M1 Macで動作していますがWindowsは検証できるマシンが手元にないので動作未確認です。
インストールはGitHubのREADMEに書かれたコマンドを実行すればできると思います。
Masuda Deleterははてラボにログインして指定されたページ分の自分の増田の投稿をスクレイピングしてローカルのDBに保存します。
取得された投稿のリストがブラウザで見られるので、そこで削除するものを選んで実行すると、またログインして投稿を削除しにいきます。
ページのアクセスごとに読み込みと遠慮のために1秒から数秒sleepするので少し時間がかかります。
一旦投稿をローカルに保存するという過程があるため副作用として自分の投稿を検索できます。
これにより
が容易になります。
増田にはAPIがないので、IDとパスワードを使ってログインして、表示されている文章をスクレイピングしてくるという原始的なやり方になります。
(2回目からはcookieがある場合はcookieを復元してログイン状態になります。)
ユーザーが知らない外部サイトにクレデンシャルを渡すのは危険であり、サービス運営側としてもパスワードを平文で持ちたくないので、Webサービスとして実装せずセルフサービスとしております。
ユーザーによってローカルの.envファイルに書かれたIDとパスワードを使用する形です。
ソースをオープンしておりますので怪しいことをしていないかも確認ができるかと思います。
一応下にプログレスバーが出ますが、ページ遷移すると見られなくなります。進捗は進捗管理でも確認できます。
取得された投稿はリアルタイムで画面に反映されないのでブラウザをリロードしてください。
増田のID、タイトル、本文の省略、投稿日時、ブクマ数、トラバ数が表示されます。
「あとで消す」投稿をチェックし、「あとで消す」記事をついに消すボタンで削除を実行します。
チェックは別のページに遷移しても有効です。
こちらは実行した時点で表示されているページのみリアルタイムに画面に反映されます。
投稿の全文を見られます。タグ等は取得しないのでテキストのみになります。
投稿を個別に取得してローカルの文章とブクマ数とトラバ数を更新します。
対象の投稿のタイトルを空に、本文をスペース1文字にしにいきます。
処理の進捗(何件中何件処理済みか)を見ることと、処理を停止させることができます。
排他処理(取込と取込、特定IDの削除と同じIDの削除等)にしているので動いていなそうな処理を停止して再度処理を実行するときに使います。
停止する場合は停止ボタンを押すか、それでも停止しそうにない場合は強制停止ボタンを押してください。
「停止」は今行っている最中の処理ではなく次以降の処理を停止するという形になります。
停止ボタンを押したときに4ページ目を取得している場合は、5ページ目の取得を始める前に処理を終了することになります。
そのためプロセスそのものが止まっている場合は停止されません。
「強制停止」はプロセスをkillします。スクリプト名とプロセスIDでプロセスを検索して子プロセスも含めてkillします。
おまけとして、投稿日とブクマ数、投稿日と3ブクマ以上の投稿の件数、投稿時間(hour)ごとの1ブクマ以上の投稿の件数のグラフが見られます。
ブクマが付いた瞬間ではなく投稿日時なので、いつの時期に投稿した、何時に投稿した増田が活きが良いのかを見られる程度です。
集計データを別に持っていないので増田を削除するとグラフに使用されるデータも消えます。
私はこれで多いときには4000件程度あった増田を3000件程度に減らしました。
これを開発する前からも増え続ける増田の削除に日々勤しんでいたので総数はもっと多いはず。
まだまだ削除したいです。
たまに
Message: unknown error: net::ERR_CONNECTION_CLOSED
というSeleniumのエラーが出て処理が実行されないことがあります。再度実行してください。
フロントエンドがレガシーなのでMasuda Deleterの開発に飽きていなければもう少しモダンにリプレースしようと思っています。
使用していないDjango REST frameworkがrequirements.txtに入っているのはその名残です。