#PHPスクリプト
Text
お絵かき掲示板 PHPスクリプト Petit Note v1.38.6リリース
ChickenPaint Be更新。
レイヤーパレットのアイコンを更新。
レイヤー結合アイコンのデザインが変わりました。
レイヤーパレットに複製アイコンを追加。
1タップでレイヤーを複製できます。
3 notes
·
View notes
Text
アップデート情報
🌟 新機能
TumblrにアクセスするためのPHPスクリプトの書き方ガイドを作成しました。相互フォローをリストアップしたり、フォローしたブログを最終投稿時間順に並べ替えたりする方法を作成する例があります。こちらをご覧ください。
Android版アプリで、投稿のブーストが使いやすいように再設計されました。
Web版で古いキーボードショートカット（ALT+C、ALT+R、ALT+Q）を使用しても、新しいショートカットがどんなものであるかについての通知が表示されなくなりました。最後に注意点として、新しい投稿を作成するショートカットはCだけになり、すぐにリブログするショートカットと表示中の投稿を予約投稿に入れるショートカットはそれぞれSHIFT+RとSHIFT+Qになりました。
Tumblr投稿のリンクにhref.liリダイレクトサービスが使用されなくなりました。
🛠️ バグ修正
今週火曜日に短時間、ダッシュボードのフィードとブログに投稿が表示されませんでしたが、その問題は修正済みです。引き続き問題が発生している場合はサポートまでご連絡ください。
Web版で、ログイン後に探索ページが正しく再読み込みされない問題が修正されました。
Web版で、インスタントメッセージのタイムスタンプの「今日」が「過去24時間以内」ではなく、実際の「今日」になるように修正されました。代わりの説明：インスタントメッセージのタイムスタンプがタイムトラベルしなくなりました。
Web版で、予約投稿ページが投稿の公開日時を常にUTC（協定世界時）で表示するため、いくつかの投稿が実際の公開時間より1日前または1日後に予定されているように見えるバグが修正されました。
リンクプレビューのジェネレーターで、Etsyのリンクが投稿のリンクブロックにならない問題が修正されました。
Web版で、ブログ設定からバッジを購入する際に発生していたクラッシュが修正されました。
先週水曜日にパスワードリセットのメールが送信されるのに時間がかかっていました。すぐに修正されたので、以前と同じようにすぐに届くはずです。
🚧 現在対応中
一部のユーザー（特に古いデバイスを使用している方）において、iOS版アプリのクラッシュが発生しています。アプリのアップデートでこの問題は修正されました。Appleから許可が下り次第、リリースする予定です。
🌱今後の予定
もうすぐiOS版アプリから予約投稿をシャッフルしたり一時停止したりできるようになります！
問題が発生していませんか？そんな時は、サポートリクエストを送ってください（英語でのみ対応）。できるだけ迅速に対応させていただきます。
共有したいフィードバックがありますか？「Work in Progress」ブログ（英語のみ）をチェックして、コミュニティで議論を始めましょう。
Tumblrを直接サポートしたいですか？Tumblrマートの新しいサポーターバッジをチェックしてください！
28 notes
·
View notes
Text
土曜日(2024-09-28)は那覇市町村自治会館でよろしくお願いいたします。
フィクションですが一応ちゃんとした内容の資料です。※事情によりまだ作成中
#phpcon_okinawa
0 notes
Text
0 notes
Text
「御郷が知れますわね！」と言われそうな私の愚痴について無駄に長い釈明文
「クソが！」
独り言にしては少し大きめな声が、私の口から漏れた。
我ながら端ないと思う。しかし泥水すすりっぱなしの私らしい独り言だ。
平和な休日を陰気で鬱々とした気分でスタートしているように思えるかもしれないが、否定しておく。
少なくとも今日という休日は、清々しいスタートを切った。(なんせ前日までの疲労蓄積で、12時間寝たからね！)
ではなぜ……あの様な下衆な言葉を吐くに至ったのか……。
事件のキッカケと始まり
「外暗っ！マジで！？ウケる！」
今から約12時間前のAM1:00。私の休日がスタートした。
最近の私はといえば、まったく進んでいなかったhtml/css、javascript、phpという言語を同時進行的に学んでいる。
なぜこんな無茶をやっているか。
頭の中にある作りたいコンテンツイメージを実現するため、静的、動的のコーディングを同時に学ぶ必要があるため
同時である必要はないのだろう。むしろ同時にやっちゃいけない気がする。
たぶん、おそらく、きっと、世の中のエンジニアは
HTML
↓
CSS
↓
Javascript(もしくはPHP)
といったように順番に勉強を進めてきた人々だ。途中、さまざまななフレームワークに触れつつ……。
私はといえば、これらをごっちゃ混ぜにして勉強を進めている。
もしこの記事を読んでいるあなたが、「いや、そんなの普通でしょ。普通みんなそうだから。」と思われたなら、一言だけ言っておく。
「うるせぇハゲ！お前と違って俺はバカなんだよ！いいな！頭良くってよ！」
安心してほしい。誹謗する気も罵倒する気もない。これは賞賛だ。褒め言葉だ。
話が逸れた。
要は今日という休日も、コーディングの勉強に費やしているのだが、その始まりが12時間前。
活動限界という足音は、すぐそこにまで近づいていた。
勉強の成果
「いや〜、頑張ったおかげで、作りたいと思ったコンテンツもサッと作れるようになったんですよ」(埼玉在住 ・40代男性)
と言いたいところだが、進捗は5%くらいだ。
「お勉強同時進行の弊害」以外の何物でもない。
さすがに「<head><meta うんちゃら><body>うんちゃら〜」とか、box-sizingといった基本構造的なことは覚えた。
おそらく簡素な静的サイトくらいなら作れると思う。
しかし、人間は欲深い生き物だ。
「ここの画像、スライドにしたいよな〜」
「よくある横にスライドするピックアップ記事とかもカッコいいよな〜」
「勉強のためにサーバー契約するのもアレだし、GoogleDriveを活用したいな」
などと、淡く浅はかな欲望に支配されている私。
「満たされたい！」という気持ちが先行しすぎて、書籍と参考サイトを行ったり来たりしている。決してたどり着かない、道もわからない、なにかを目指してとりあえず進んでいる。
結果、なにかが進んだのかどうかすらわからない。
現在に至る
「へ〜、安易にフレームワーク使うとサイトスピードに影響するのか……」
「ってことは、CSSとかスクリプトは直書きしちゃえばいいのかな？」
「あれ？そもそも最新記事とかってどうやって表示すんだ？」
「これphpとJSどっちでやるんだ！？」
すごい！
何がすごいって、情報に惑わされ具合がすごい。ぜんぜん正解に辿り着けない。
一つ学んだかと思えば、それを全否定するかのような情報に出くわす。
たとえ正解らしき情報が見つかっても、「SEOや見栄えとか考慮すると正解じゃない気がする……。」と自信がなくなる。
そして徐々に私の検索能力がエネルギー切れに近づいてるのか、グーグルというインターネッツに表示されるのは、クエリとは程遠い検索結果ばかり。
欲しいものが手に入らないストレス。
何度も何度も検索するのに、インターネッツが壊れてるとしか思えない。
「なりたい自分になろう！」なんて、夢見るだけバカだ。
ぜんぜん満たされない……。
そして、悲劇は起こった。
私の中にいる、もう一人の私が目を覚ましてしまった。
「クソが！」
「アクセス伸ばしたいからって適当なこと書きやがって！」
「この記事もその記事も、こっちの本もそっちの本も！」
「地球滅亡しろ！」
「ぜんぶ！ぜーんぶ燃やしちゃうの！」
まぁ冗談なんですけどね
私は勉強が苦手なので、どうしても非効率な方法になりがちだ。
とどのつまり、今日もまぁ疲れました。
物事を完全に理解できたとき
「点と点が繋がった！」
という表現を目にするが、私の場合
「点だけで絵を描くアートのかたですか？」
というくらい、自ら点を増やしてしまう悪癖がある。当然、点が繋がるまで人より時間がかかる。
ただし点が繋がり始めたらその後は早い。それまで蓄積してきた点が、一気に線になる。
自分で言うのもだが、こういう性格が功を奏しているのか、他人より高いパフォーマンスを出せる人と思われがちだ。几帳面な性格も手伝って、品質も割と高い(はず)。
まとめ
いかがでしたでしょうか。
お腹が減ったので何か食べようと思います。
1 note
·
View note
Text
一番簡単なのはマクロの記録です。Excelでいちどマクロを記録すれば、同じ操作が何度でもできます。
マクロだけでは実現できない定形業務は Excel VBA を使ってプログラミングすることで自動化します。大体皆さんここまではよくご存知です。
Excelだけで実現できないとかその他の定形業務は、RPAアプリを使ったりします。Windowsでは、無料の UIpath、有料の WIN ACTOR、最近 Microsoft が作った power automate desktop が有名です。Macではあまり知られていないのですが、AutomatorというRPAアプリが付属しています。この段階までならプログラミング知識はほんの少しあれば大丈夫で、実際に使ってもあまりプログラミングと言う感じはしません。
それでも実現できない定形作業はスクリプト言語でプログラミングして実現します。VBScript や AppleScript がそうです。Google の GAS もスクリプト言語です。
定時作業はスクリプトファイルとタイムスケジューラー（ジョブスケジューラー）を使うことで実現できます。ここまでくると定形作業なら大体自動化できると思います。
それでも自動化できない複雑な作業は、一般のC#やPHPなどの言語を使って専用のアプリケーションを開発します。
0 notes
Text
PHPの公開停止について
突然ですが、1月13日をもちましてPoser Hotkeys Plus(PHP)の公開を停止します。
ご愛用して頂いている沢山の方々のご期待に添えず本当に申し訳ありません。
公開の停止理由ですが、ShowPoseMenuの作者から理不尽な苦情を申し立てられた為です。
先にあちらの作者がTumblrで事実と異なる事を述べられているのでここで今回の経緯と反論を交え説明させて頂きます。
作者は最初に自分のアイデア（ポーズのリスト表示）を丸パクリしたりそれらのMODで寄付を募る行動を止めろという言い掛かりを付けられてきました。
私はその作者のMODを丸パクリしている訳でもなくMODの侵害も行っていません。
PHPの説明文に「ShowPoseMenuの名前が上がったことで自分のMODを使われているようです」と言っていますがこれは全くの誤解です。
当時の記事にもありますが、これはその当時ポーズ管理MODで有名だったShowPoseMenuに似た機能とPoser Hotkeysの便利機能を合体させたようなMODですと使用者に分かり易く書いただけでありShowPoseMenuはスクリプトを含め一切使用しておらず、例えるなら同じリスト表示できるQuickMenuのポーズ管理機能でも良かったのです。
しかしShowPoseMenuという名前を出してしまった以上失礼にあたると思いクレジットのSpecial Thanksにあえてこの作者の名前を記載させて頂いただけなのです。
また寄付を募る行動＝金儲けと言っておられますが、これは全く意味合いが違います。
以前にもTumblrに書きましたが、高度なスクリプトMODの開発（主にプログラミング）には多大な時間と労力と忍耐を要する作業のため一般のMODを作るのとは訳が違います。
あくまで私は開発のモチベーションを上げて皆さんにより便利なMODを提供したいという気持ちで始めただけであり、作者の言う金稼ぎに利用しているのではありません。
作者はそこを履き違えているようで、その証拠にパトロンを始めた後もPHPは無料で公開を続けていましたし寄付も気に入った方だけ任意で寄付して頂く形式を取っている為お金稼ぎと言える額にもなっていません。
それでも作者は額には関係ないと言っていましたが、私からするとこれは2chで俗に言う「嫌儲」と云う言葉が相応しく自分とよく似たMODで寄付を募る行動が気に食わないというだけの屁理屈を付けているだけに感じます。
作者は自分のアイデアを丸パクリをするなと主張していますが、PHPの公開当初でもポーズをただリスト表示するだけではなく、そのリストの検索機能、メニュートップに現在選択しているポーズ番号の表示、選択中のメニューを一から辿らなくても済むように最後に選択したメニューを保持する機能等、これらはShowPoseMenuにはない私独自のアイデアも付け加えているため作者が主張するアイデアの丸パクリに当たりません。
PHPをご愛用して頂いている方々ならご存知だと思いますが、PHPはPoser Hotkeysを基にしたポーズ管理MODでありポーズの再生をより便利にするために実装した機能（スライドショー・自動TFC・FOV機能・表情メニュー・作成した表情のカテゴリー化・表情編集機能・舌装備メニュー・NPC操作など）の大半のアイデアは自分で考えた物です。
また自分のアイデアをパクるなと言う以前にアイデア自体に著作権はありませんからその模様・取り入れについて逐一報告しなければならないという義務はありません（二度目のENBの件も同様です）
そもそも作者の言うリスト化のアイデアはAddItemMenuやQuickMenu、F.E.P等それらのMODは既に存在していましたからこれを自分のアイデアだと主張する権利もありません。
もしその様な主張が通用するのであれば現在無数にあるフォロワーMODやフォロワー管理MOD等は一体どうなるのでしょうか。
法的にアイデアの特許を取っている訳でもなく私のMODにどうこう言われる筋合いはありません。
しかしここまで言っても作者はご理解を頂けませんでした。
作者が一年休止後に再開したらPHPやOSA等の ポーズ 管理MODが増えたから仕方なく別のMOD（NiOverride Pose Adjustments）を作ったのに、私がツイッターでボーンの操作方法を研究していると匂わした途端また自分のアイデアをパクられると思い込み、ストーカー行為を受けているようで気持ち悪いと愚痴を吐かれました。
しかし私は私でポーズ・表情編集管理MODを作っているだけに過ぎず何もこの作者のアイデアを意図的に真似している訳でもありません。
私はPHPv2で位置調整機能を実装しましたがこの機能自体がボーンの位置調整と同じライブラリ関数を使っている為ボーンの調整というアイデアは直結して思い付く事なのです。
仮にこの作者のNiOverride Pose Adjustmentsが作られなかったとしてもその知識は持っていますから何れ作っているでしょうし、先に作ったからと言ってそれを作るなと言う権利がどこにあるのでしょうか。
同じポーズMODを制作している点においていくつかアイデアが被るのも致し方ない事であり、機能が似ているからと言う理由だけで類似MODは作るなと言える拘束力はありません。
私には自分が休止している間に自分のポーズ管理MODより高機能なMODが出てしまい後にも引けないから、これ以上自分と似たようなMODを作るなとイチャモンを付けているようにしか聞こえません。
そもそもこの位置調整機能やボーン調整機能はこの作者が独自に考えて作った機能ではなく、元はRaceMenuの機能の一つでありそれをRaceMenuがなくても使えるようにライブラリ化された「NiOverride」をそのまま利用しているだけに過ぎないのです。
そしてこのNiOverrideは誰でも自由に使って良いというリソースでありそれを一人で独占し、これは自分のアイデアだから使うなと言う方がおかしな話です。
更に追及しますとShowPoseMenuの最終版辺りでダンス機能を取り入れられていますが、これは散々私に言ってきたダンスというアイデアの丸パクリに当たるはずです。
作者の主張だと最初に作られたダンスMODの作者からすれば非常に迷惑な話であるのに、自分の事は棚に上げて人のアイデアを丸パクリするなと言える立場なのでしょうか？
作者の主張を論破し続けると今度はアイデアの丸パクリから取り込んでいるという言葉に変えてきましたが、取り込むという言葉に置き換えたとしてもアイデア自体に著作権はありませんしMODというものは良いアイデアは取り入れてそれを改良してさらに良いものを作っていく、これがMODの本来あるべき物ではないのでし��うか。
そしてまだ議論が終わっていないのに「理解できないならもう好きにしろ」と一方的に話を切られこれ以上は連絡もしないという身勝手極まりない態度でした。
作者のTumblrの最後の方で「多少の恩や一考の価値もない」などと言っておられますが、私は自分ではどうしても上手く実装できなかった選択型LUTをDiamond ENBに快く実装して頂いた件について忘れていませんし今でも感謝しております。
そして私の本心は同じポーズ管理MODを作られているので、近い内にお互いに情報交換などをして共同開発できるようなMODを作りたいと思い最近ツイッターの方でもこちらからフォローをさせて頂いていました。
それがこの様な理不尽な苦情を申し立てられて本当に残念な気持ちです。
DMでも言ったのですが私の言動をご理解できないのでしたらあなたの意思を尊重しPHPの開発及び公開も停止すると言いましたので私はポーズ管理MODから手を引きます。
その代りPHPを超えるMODを責任持って作って頂くように申しましたので、今後ポーズ関連についてはこの作者にサポートをして頂くよう宜しくお願い申し上げます。
58 notes
·
View notes
Text
ぷろぐらみんぐ言語
☆c言語
全てのプログラミング言語のﾍﾞｰｽ
１９７２年
ーーーーーーーーーーーーーーーーーーーーーーーー
☆swift
2014年にAppleから発表された、iOS開発向けの新しい言語
iPhone・iPad、Macで使用
ーーーーーーーーーーーーーーーーーーーーーーーーーー
☆web系
・ｈｔｍｌ（HyperText Markup Language）
２０１４年にｈｔｍｌ５が勧告 記述がシンプルになった
・ｃｓｓ
ｈｔｍｌで記述されたコードの文字の色や大きさ等を装飾する
・javascript
ブラウザに作業をさせるためのスクリプト言語
文字サイズ、デザインや色の変化など、動きを出すために幅広く使用さ
れ、ほとんどのWeb ページ に JavaScript が読み込まれている
・php（スクリプト言語）
ｈｔｍｌに組み込む事が出来る
1 note
·
View note
Text
【 PHP 】PHP8に入門してみた 3日目 序章
【 PHP 】PHP8に入門してみた 3日目 序章
PHP8技術者認定初級試験 が始まるようなので 試験に向けて (できるだけ)勉強しようと思います！ 使用する書籍は独習PHP 第4版（山田 祥寛）｜翔泳社の本 (shoeisha.co.jp) となります。
イントロダクション
PHPとは
まずはPHPとは何なのか。PHPとはHypertext Preprocessorの略でサーバ再度で動作する「スクリプトの実行環境」です。
どこをどう抽出したらPHPになるんでしょうね(笑)
簡単に言うとWebアプリケーションを作成し公開するための環境(と対応する言語)ということだと思います。
Webアプリケーションに特化していると考えてよいのでしょうかね。
それともPyhtonのようにコンソールアプリケーションを開発することもできるのでしょうか？
ほとんどの文脈では「PHP = Webアプリケーション」…
View On WordPress
0 notes
Text
お絵かき掲示板 PHPスクリプト Petit Note v1.29.1リース
｢SNSで共有する｣にBlueskyを追加しました。
Twitter、マストドン、Misskey、Blueskに記事を共有できます。
3 notes
·
View notes
Text
はじめてUNIXで仕事をする人が読む本
UNIXの教育を受けないままIT業界に就職した人に最適な、仕事でUNIXを使うための最低限の基礎知識をまとめた教科書をお届けします。
株式会社創夢 監修
木本雅彦、松山直道、稲島大輔 著
定価：1,944円（本体：1,800円）
発売日：2018年6月29日
形態：B5変型版（248ページ）
ISBN：978-4-04-89306-1
Amazonで購入する
達人出版会で電子書籍を購入する
サポート／追加情報
本書が対象とする読者は以下のような人である。
情報系の学部2年生レベルのUNIX講義の内容を学びたい人。
情報系の大学で学んだものの、ほとんどUNIXの教育を受けないまま、IT業界に就職することになった人。
就職して2～3年になるが、先輩から「こんなことも知らないのか」と叱咤されることがあるエンジニア。
UNIX業界のITエンジニアとして仕事を始めると、現場には大きく2種類の仕事があることがわかると思う。1つはUNIXで動作するソフトウェア（場合によってはUNIXカーネルそのもの）を開発する仕事。もう1つは、UNIX上で動作するソフトウェアを使って環境やサービスを構築し、それを運用する仕事である。
現在では両者はほぼ分業されているが、1990年代以前からUNIXの仕事をしている人にとって、両者はどちらもできて当たり前のことであった。ソフトウェアを開発する人も、自分たちのサーバやネットワークは自力で構築して運用しなければならない。運用構築系の仕事をする人も、ソフトウェアに不具合があったら自力でデバッグまでしなければならない。その際に、カーネルの解析が必要になる場合もある。
本書では、開発と環境構築運用の両方の内容をカバーしようと試みた。それが「UNIX的なやりかた」だと考えるからである。
もし、読者の中に、今の自分がどちらかの知識しか持っていないと感じる人がいたら、ぜひ不足している知識の底上げに本書を利用していただきたい。
（本書「はじめに」より）
◆著者/監訳者紹介
■木本雅彦（きもと まさひこ）
1972年生。東京工業大学大学院情報理工学研究科博士課程修了。博士（理学）。2003年より株式会社創夢に勤務。カーネルドライバ開発から、ネットワークアプリケーション、Webアプリケーション開発までの幅広いレイヤーをこなす。普段はFreeBSDをメインの生活環境として使う。また、2007年より小説家としての執筆活動も行う。主な著作に「くあっどぴゅあ」（ファミ通文庫）、「星の舞台からみてる」（ハヤカワ文庫JA）、「人生リセットボタン」（PHP研究所）などがある。UNIX技術者と小説家の両方の経験を活かし、ASCII.Technologies上で、IT業界小説「株式会社初台アーバンギルド」を連載していた。
■松山直道（まつやま ただみち）
1964年東京生まれ。株式会社創夢創業メンバー兼現取締役。WIDEプロジェクトに初期から参加しており、主にインターネット関連の研究活動等に従事。特にIPv6関連技術の研究開発や普及を推進するコミュニティにおいて積極的に活動している。またルータ等ネットワーク関連機器類の開発業務にも携わる。社内のCISO（最高情報セキュリティ責任者）を務める。自宅のネットワークは、10年以上前から/29と/48のデュアルスタック。日本UNIXユーザ会幹事。
■稲島大輔（いなじま だいすけ）
1982年生まれ。2007年より株式会社創夢に勤務。組み込み機器へのブートローダ・カーネルの移植から、ネットワークプロトコルの実装など、主に低位層から中位層の業務を担当。趣味では関数型言語でアプリを作ったりすることの方が多い。UNIX環境としては2014年現在でもデスクトップ・サーバともにNetBSDを常用。pkgsrcを気に入っている。
■株式会社創夢（そうむ）
1984年創立。創立以来一貫して、UNIXとインターネットを事業の主軸においている。JUNET時代には創夢を経由してネットに接続する企業も多かった。かつてはX11R5のマニュアルを出版するなど、X Window Systemに力を入れていた時期もあった。エンジニアが作ったエンジニアのための会社であり、エンジニアが楽しく仕事ができる環境を作るというビジョンを持っている。事業範囲はUNIXの移植、デバイスドライバの開発、研究用ソフトウェアの開発、サーバ・ネットワークの設計・構築・運用管理など。「普通の会社だとこういう仕事引き受けてくれないんだよなあ」という種類の面倒な仕事を、軽いフットワークと重量級の馬力でさばくのが得意な、特異な会社。
◆目次
第1部 生活環境編
第1章 ログインログアウト
1.1 そもそもログインとは
1.2 TELNETによるリモートログイン
1.3 SSHによるリモートログイン
1.4 ログアウト
第2章 UNIXの基本操作
2.1 シェル
2.2 リダイレクションとパイプ
2.3 UNIXのファイルシステム
2.4 基本のファイル操作
2.5 パーミッション・オーナーの管理
2.6 正規表現
2.7 grep
2.8 sed
2.9 awk
2.10 アーカイバ
2.11 その他のコマンド
第3章 テキストエディタ
3.1 基本のテキストエディタ
3.2 限定された環境でのファイル編集
3.3 ViとVim
3.4 Emacs
第4章 作業の自動化（シェルスクリプト）
4.1 シェルスクリプトによる作業自動化の必要性と利点
4.2 Bourne shellについて
4.3 簡単なスクリプトの作成と実行
4.4 シェルスクリプトの実用例
第5章 オンラインマニュアル
5.1 オンラインマニュアルを必要とする場面
5.2 氾濫する情報の危険性
5.3 manコマンド
5.4 infoコマンド
5.5 ヘルプメッセージ
第6章 セキュリティ
6.1 UNIXにおけるセキュリティ
6.2 ルート権限の獲得方法
6.3 共通鍵暗号と公開鍵暗号
6.4 SSHの応用
6.5 PGPによる暗号化、電子署名
第7章 UNIXシステム管理
7.1 UNIXにおける管理作業
7.2 起動とシャットダウン
7.3 ユーザとグループの管理
7.4 パッケージ管理
7.5 TCP/IPネットワーク管理
7.6 DNS（名前サービス）
7.7 サービスの管理
7.8 トラブルシュート
第2部 プログラミング環境編
第8章 UNIXプログラミング環境
8.1 プログラミング環境概要
8.2 C言語による開発実例
8.3 Javaによる開発実例
8.4 LL言語による開発実例
第9章 バージョン管理システム
9.1 バージョン管理システムとは
9.2 バージョン管理システムの種類
9.3 バージョン管理システムの使い方
9.4 Subversionの使い方
9.5 Gitの利用方法
第10章 ソースコードからのドキュメントの作成
10.1 はじめに
10.2 ドキュメント生成ツールの種類
10.3 ドキュメント生成ツールの利用方法
第11章 ソフトウェアライセンス
11.1 ライセンスを考慮する理由
11.2 オープンソースライセンス
第3部 ネットワーク技術編
第12章 UNIXとネットワーク技術
12.1 TCP/IP実装の公開と普及
12.2 LANとWAN
12.3 ネットワーク端末としてのUNIX
第13章 OSI参照モデル
13.1 OSI参照モデル
13.2 TCP/IPとOSI参照モデル
第14章 データリンク層
14.1 データリンクとは
14.2 データリンクの基本
14.3 Ethernet
14.4 無線LAN
14.5 Point-to-Point接続
第15章 IPと関連プロトコル
15.1 IPの基���
15.2 IPv4とIPv6
15.3 IPアドレス
15.4 特殊なIPアドレス
15.5 ルーティング
15.6 関連プロトコル
第16章 TCPとUDP
16.1 ポート番号
16.2 UDP
16.3 TCP
16.4 TCPのコネクション
16.5 TCPの通信
16.6 TCP通信の制御
16.7 TCPとUDPの使い分け
第17章 アプリケーションプロトコル
17.1 Webアクセス（HTTP/HTTPS）
17.2 電子メール（SMTP/POP/IMAP）
17.3 リモートログイン（TELNET/SSH）
17.4 ファイル転送（FTP/rsync）
17.5 ファイル共有（NFS/SMB）
17.6 VoIP（SIP/RTP）
17.7 システム運用管理（DNS/DHCP/NTP/SNMP）
17.8 Xプロトコル
第18章 IP関連の技術
18.1 名前解決
18.2 IPアドレスの付与
18.3 アドレス変換（NAT・NAPT・IPマスカレード）
18.4 トラブルシューティング
第19章 ネットワークセキュリティ
19.1 ネットワーク上の攻撃
19.2 認証システム
19.3 通信フィルタとファイヤウォール
19.4 通信の暗号化
19.5 VPN
1 note
·
View note
Link
from 薫のhack - FreeBSD や セキュリティ、プログラミングの記録 http://kaworu.jpn.org/kaworu/
0 notes
Link
スクリプト言語「PHP」の新しいメジャーバージョン「PHP 8」が、11月27日にリリースされた。言語仕様の見直しと拡充、エラー処理の改善などにより、これまでありがちだったミスを排し、ソースコードをより簡潔に記述で via Pocket
0 notes
Text
WEBアプリケーションとは何ですか？
定義
Webアプリケーションは、WebブラウザーとWebテクノロジーを利用してインターネット上でタスクを実行するコンピュータープログラムです。
概観
何百万もの企業がインターネットを費用対効果の高い通信チャネルとして使用しています。これにより、目標市場と情報を交換し、高速で安全な取引を行うことができます。ただし、効果的なエンゲージメントは、ビジネスが必要なすべてのデータをキャプチャして保存でき、この情報を処理してユーザーに結果を提示できる手段を備えている場合にのみ可能です。
Webアプリケーションは、サーバー側スクリプト（PHPとASP）を組み合わせて情報の保存と取得を処理し、クライアント側スクリプト（JavaScriptとHTML）を使用して情報をユーザーに提示します。これにより、ユーザーはオンラインフォーム、コンテンツ管理システム、ショッピングカートなどを使用して会社とやり取りできます。さらに、従業員はアプリケーションを使用して、場所やデバイスに関係なく、ドキュメントの作成、情報の共有、プロジェクトでの共同作業、ドキュメントの作業を作成することができます。
Webアプリケーションのしくみ
Webアプリケーションは通常、JavaScriptやHTMLなどのブラウザーがサポートする言語でコード化されています。これらの言語は、プログラムを実行可能にするためにブラウザーに依存しているです。一部のアプリケーションは動的であり、サーバー側の処理が必要です。その他は完全に静的で、サーバーの処理は必要ありません。
Webアプリケーションには、クライアントからの要求を管理するためのWebサーバー、要求されたタスクを実行するためのアプリケーションサーバー、および情報を格納するためのデータベースが必要な場合があります。アプリケーションサーバーテクノロジは、ASP.NET、ASP、ColdFusionからPHPやJSPまでにわたります。
プロジェクトに合ったアプリケーションサーバーテクノロジーを選択する必要があります
典型的なWebアプリケーションの動作は次のとおりです。
ユーザーは、ウェブブラウザまたはアプリケーションのユーザーインターフェースを介して、インターネット経由でウェブサーバーへのリクエストをトリガーします
Webサーバーはこの要求を適切なWebアプリケーションサーバーに転送します
Webアプリケーションサーバーは、データベースのクエリやデータの処理など、要求されたタスクを実行し、要求されたデータの結果を生成します。
Webアプリケーション・サーバーは、に結果を送信し、Webサーバ要求された情報または処理されたデータを
Webサーバーは、ユーザーのディスプレイに表示される要求された情報をクライアントに返します。
Webアプリケーションの例
Webアプリケーションには、オンラインフォーム、ショッピングカート、ワードプロセッサ、スプレッドシート、ビデオと写真の編集、ファイル変換、ファイルスキャン、Gmail、Yahoo、AOLなどの電子メールプログラムが含まれます。人気のあるアプリケーションには、Google AppsやMicrosoft 365があります。
Google Apps for Workには、Gmail、Googleドキュメント、Googleスプレッドシート、Googleスライド、オンラインストレージなどがあります。その他の機能には、カレンダーやドキュメントのオンライン共有があります。これにより、すべてのチームメンバーが同じバージョンのドキュメントに同時にアクセスできます。
Webアプリケーションの利点
ブラウザに互換性がある限り、OSやデバイスに関係なく、複数のプラットフォームでWebアプリケーションが実行されます
すべてのユーザーが同じバージョンにアクセスし、互換性の問題を排除
それらはハードドライブにインストールされないため、スペースの制限がなくなります
サブスクリプションベースのWebアプリケーション（SaaSなど）でのソフトウェアの違法コピーを削減します
ビジネスに必要なサポートとメンテナンスが少なく、エンドユーザーのコンピューターの要件が低いため、ビジネスとエンドユーザーの両方のコストが削減されます。
結論
企業や個人の間でのインターネット利用の増加は、企業の運営方法に影響を与えています。これにより、企業は従来のモデルからクラウドベースおよびグリッドモデルに移行して、Webアプリケーションが広く応用されるようになりました。Webアプリケーションにより、企業は運営を合理化し、効率を高め、コストを削減することができます。
電子メールクライアント、ワードプロセッサ、スプレッドシート、およびその他のプログラムなどのこれらのオンラインアプリは、デスクトップバージョンと同じ機能を提供します。 ただし、複数のプラットフォームに動作し、より広範囲に到達でき、どこからでも簡単にアクセスできるという利点もあります。
https://innotech-vn.com/jp/web-application/
Innotech Japan は、ベトナムでの高品質サービスに焦点を当てたソフトウェアアウトソーシング企業です。 Innotech Japanでは、創造、革新、開発、高度なソリューションに取り組んでいます。 お客様からのすべての要件と期待に応える幅広いソフトウェアサービスを提供しています。 私たちは、世界中の専門的なソリューションとビジネスサービスを通じて、これらの高度なテクノロジーをお客様��価値に変えます。
ソフトウェアアウトソーシング開発に関する質問については、Innotech Japanの専門家にお問い合わせください。
0 notes
Photo
youtube
Poser Hotkeys Plus v2.1
Poser Hotkeys Plus(PHP)をv2.1にアップデートしました。
主に設定メニュー・総合 ランチャーの追加や 表情機能の強化を行っています。
■主な新機能
表情ランダム再生機能
ホットキー（デフォルト：Shift+9） を押すとランダムポーズ再生のように表情を作成したプリセットからランダムに表情をつけます。
表情は全体のカテゴリーか選択したカテゴリー内からランダムに選択できるので適当に表情をつけたい場合に便利です。
表情機能の各オプション
表情自動再生：ポーズ時に 作成した表情を 自動的に付けます。
表情は 詳細設定で 指定した表情かランダムな表情を付ける事がになります。
表情強度指定再生：作成した表情の強さを無視して指定した強さで再生します。これにより表情の強度毎に表情を作成する必要がありません。
表情強度ランダム再生： 作成した表情の強さを無視して ランダムな 強さで再生します。同じ表情でも強さが違うと表情も違ってくるのでバリエーションが増えます。
表情取得ホットキー
これまでアクターの表情を取得するにはMCMから行う必要があり不便でしたが、表情取���ホットキーの追加によりプレイヤー・NPCの表情を いつでも 取得できるようになりました。
選択中の不要な表情もその場で削除するホットキーも追加しています。
ショートカット設定メニュー
MCMの設定項目をメニューからワンキーで設定できるようになります。
ヘッドトラッキングなどの設定をよく変更する人は 毎回MCMを開く必要がなくなるのでポージングが非常に捗るかと思います。
総合ランチャー
ポーザー・お気に入り・表情・設定の各メニューにアクセスできるランチャーを追加しました。
ホットキーを節約したい方や ゲームパッドを使用している人 に重宝するかと思います。
——————————————————————————
各メニューの総合ランチャーを追加
各設定のショートカットメニューを追加
上記の操作魔法を追加
ポーズ時に表情を自動再生するオプションを追加
表情を自動再生した際の表情を指定する設定を追加
表情再生時の強さを指定するオプションを追加
表情再生時の強さをランダムにするオプションを追加
表情のランダム再生機能を追加（デフォルト：Shift+9）
上記の表情ランダム再生時のオプションを追加
表情を取得しプリセットへ保存するホットキーを追加
選択中の表情を削除するホットキーを追加
グラビアモードに全ポーザーを追加
グラビアモードで二人以上のアクターを同時再生すると順番通りに再生されない不具合の修正
操作魔法を無効にしても一部の魔法が消えない不具合の修正
各オプション設定を他のセーブデータと共通化（設定中のオプションが他のセーブデータでも引継がれます）
その他スクリプトの改良
v2.0からのアップデートの場合クリーンセーブの必要はありません。
LE版
https://www.nexusmods.com/skyrim/mods/90896
SE版
https://www.nexusmods.com/skyrimspecialedition/mods/17743
109 notes
·
View notes
Link
技術選定について最近の私生活や労働を通して考えたことを、つらつらと書き下した文章（ポエム）です。 他者に伝えることではなく、頭の中におぼろげに存在する考えを言語化して客観視することを目的に書いた雑記なので、 誰かにとっては当たり前なことも、誰にも当てはまらないことも書いてあるかと思います。 またここで述べることは、こうやって書き下した時点での僕の考えに過ぎないので、明日僕は全く別の考えを持って行動しているかもしれません。 いわばこれは僕の思考のスナップショットです。 諸々、ご容赦ください。 技術選定そのもの ソフトウェアの開発においては、どこからが開発者の作るものの責務であり、どこからがその下のレイヤの責務であるかを（あるときには能動的な思考より、またあるときには受動的な思考により）明確にする、という知的活動を繰り返していくことになります。 この営みは、開発するソフトウェアに関する前提を定める営み、とも言い換えられます。 例えばユーザ空間で動く、そこまで高いパフォーマンスが求められるわけではないソフトウェアを書いているのであれば、開発者はハードウェア資源の管理のことはあまり気にしないでしょう。この時開発者は、OS の提供する抽象化層と上手く会話をしながら所望の機能を実現するのが自身の責務であり、そこから先は OS の仕事である、という前提を（無自覚かもしれませんが）導入しています。 また FaaS 上で動作することを前提とした API エンドポイントをソフトウェアを開発・運用することを考えます。 この際の開発者の責務は、既にパースされ、構造化されたリクエストを受け取り、それを元にレスポンスを生成するような関数を FaaS プロバイダに提供するところまでです。 一方そこから下 —— 例えばユーザからの通信を受け取ったときに、適切にアプリケーションランタイムを起動し、開発者から提供された関数に通信を流すというような仕組み —— を提供し、健やかに動かし続けるのは、FaaS プロバイダの責務になります。 このような 「前提の設定」 は、ソフトウェア開発だけではなく、システム開発においてもその初期に求められることです。 例えば Web システムを開発しようとすると、何を永続化ストレージとするのか、認証認可の仕組みは開発する Web アプリケーションの中に持たせるのか、サーバサイドで動く Web アプリケーションはどんな言語でどんなフレームワークを用いて作るのか、……というような、様々な前提を定義していくことになります。 そして定められた前提同士を上手くつなげたり、その前提に立脚する新たな何かを作ることで、開発を進めていくのです。 ここからは、このような「前提の設定の営み」、つまり 「あるシステムの仕様が与えられたときに、それを満たすようなシステムを構成するために、前提とするものを列挙する営み」 のことを、技術選定 と呼んでやることにします。 技術選定の自由度 前項で定義した技術選定とやらは、兎にも角にも自由度が高く、厄介なものです。 システムを構成する手段は一つではないためです。 例えば「アンケートフォームをユーザに見せ、答えを回収し、その結果を（加工した上で）なんらかのデータストレージに蓄積したい。そのデータは管理者が簡単に閲覧できるようにしたい。」というニーズがあり、これを解決するシステムを作ろうとしたとします。 このとき Google フォームに少し GAS を連携させてやる、というのは選択肢の一つです。 この選択肢は一見貧相にも見えるかもしれませんが、SaaS に強く依存することでダウンタイムをあまり気にする必要がなくなるという点で、（要件を満たせている限りは）立派な選択肢である、と筆者は考えます。 一方自前で RoR や Django 製のアプリケーションを一つ作ってやり、その上でサーバサイドのロジックを担保してやってもいいでしょう。 要件や開発者のスキルセットによっては、フレームワークを使わないべた書きの PHP で実装してやる、というのも選択肢になりうるかもしれません。 またユーザのブラウザ上で表示される Web ページを構成するのには、HTML+JS+CSS をベタ書きしてもいいですし、React + styled-components のようなやり方を取るものいいでしょう（最近の筆者は専ら後者のやり方を取っています）。 こうして作ったアプリケーションを PaaS や FaaS に乗せるのか、それとも何処かで VM を借りて乗せるのか、オンプレの環境を構築するのか、というところも自由です。 自由度からくる評価への動機 しかし自由度が高いからといって、どんな選択肢をとってもよい、ということではありません。 技術選定という選択は、後の「運用」「改善」の 2 つの営みに大きな影響を与えるからです。 例えば先だって例示したアンケートを回収・表示するためのシステムを Google フォーム + GAS で実現したとします。 このときシステムの健やかな動作を担保するのは、そこまで難しいことではありません。システムそのものの運用に関する心配ごとは少ないでしょう、 ただこのシステムは、あくまで既存の SaaS が提供している機能で実現できる機能しか実現できませんから、どこかで技術的な壁にぶつかる可能性があります。 一方このシステムを自前で Web アプリケーションを作ることで実現したのなら、工数さえかければ大抵の機能追加をできるでしょう。 しかしこの場合は初期の開発コストとその後の運用コストが一定大きくなることが容易に予想できます。 いくら注意してコードを書いても、障害は起こってしまうものです。 このような背景から、技術選定において、数ある選択肢たちの中から「最適なもの」を選びたいという気持ちが芽生えてきます。 よく「技術選定は難しい」と言われますが、その難しさの本質はこの「何が最適か」を考える部分であるように思います。 4 つの評価軸 しかしここでいう「最善」を定義するためには、各選択肢を評価してやる必要があります。 そして評価のためには、評価基準が定義されていなくてはなりません。 基準のない中で何かを比べるのは「悩む」と同じ程度の知的活動であり、ある基準のもと何かを比べてみて、ようやく「考える」のフェーズに到達するものです。 逆に技術選定は、まずこの評価基準についての認識をチーム内で揃えてやるところからスタートするべきである、と筆者は考えます。 また評価基準はできるだけ明確であることが好まし��でしょう。 評価基準が明確であればあるほど、（組織の全員が満足できるような選択肢でなくとも）納得感を形成しやすいからです。 では具体的な評価基準としては何を採用するのが好ましいのでしょうか。 この問いに対する答えは人によって異なるでしょう。 筆者の場合、普段は @timakin さんの『理想の技術選定』という記事 で挙げられている以下の 4 つの評価軸を採用しています。 非常に明瞭でよい言語化だと思います。 サービス要件の担保 経済性 開発生産性 技術信頼性 評価軸を支配する変数 しかしこの 4 つの軸は、いくつかの（技術選定により得られた）「前提」のセットを相互比較するための 指標 に過ぎません。 「技術選定の結果得られたパターン A は、パターン B に比べて経済的である」だとか、 「パターン A, B, C は、経済性の観点から見ると順に ◎ ○ △ と評価され、開発生産性の観点から見ると順に ○ △ ◎ と評価される」というような感じで用いられるものです。 となると、今度は、これらの軸たちがどう決まっているのか —— つまり、これら 4 つの軸が依存している変数とはなんなのか、というところが気になってきます。 この変数に関する認識が甘ければ、これらの指標を正しく見積もることも難しいからです。 そこでここからは、各軸の評価において筆者が意識している、各軸を支配する変数についてを、順に紹介したいと思います。 まず サービス要件の担保 は、およそ「その技術選定の結果、所望のシステムは実現しうるか」という趣旨の軸です。 そのため特筆すべき変数もなく、ちゃんと事前に定義したことが実現できるのであれば、一律最高評価を与えることにしています。 一方 経済性 という軸について考えると、この背後には次のような変数があります。 組織の資金力 サービスが価値を発揮する状態になるまでに必要な人件費 プロダクトの利益構造からくる、そのプロダクトの運用にかけていい費用 大まかにいうと、開発に投資する余力と、イニシャルコスト、そして単位時間あたりのランニングコスト、の 3 つが変数になるわけです。 これらの数値はシステムの仕様（＝何を作るか）がある程度の精度で定まっていれば、大雑把にでも見積もることができるものですから、技術選定の段階で概算値を持っておくとよさそうです。 そしてこれらの数値をもとにすると「経済性」という総合的な指標を、ある程度の解像度で評価してやることができます。 次に 開発生産性 という軸の背後にあるのは、以下のような変数たちです。 学習に必要な時間 オンラインに存在するドキュメントの量 関心の分離により期待される、並列作業の効率化度 DRY (Don’t Repeat Yourself) の実現のしやすさ テストコードの書きやすさ このうち前半 2 つについてはかなり定量的に評価しやすいものです。 一方最後の 3 つについては、個人開発や過去の経験があれば定量的に評価できるものの、プロダクト初期においては定性的な評価が限界であるように思います。 なお関心が分離しやすいアーキテクチャほど、その分離の境界にはきちんとしたインターフェイスが定義されており、開発のオーバーヘッドが大きくなります。 そしてこのオーバーヘッドが開発スピードに与える影響は、大きな組織ほど無視しやすく、小さな組織ほど無視しにくいものです。 したがって 3 つ目の「関心の分離により期待される、並列作業の効率化度」というのは、組織規模によって変動する値である、と考えるべきです。 最後の軸である 技術信頼性 については、これらの変数あたりが、大雑把に情報を集めやすく使い勝手もよいです。 開発母体のレピュテーション GitHub 上でのスターの数・コントリビュータの数 GitHub 上での Issue や Pull Request の処理フロー・スピード ダウンロード数（npm などの場合容易に確認できる） GA 後に経過した時間 ソースコードの LOC や構造の綺麗さなんかも大まかに評価しておくと、社内でメンテナンスが続けられるようなシロモノか事前に分かるので、少しだけ安心感が得られるかもしれません。 ただ小さな組織ではメンテナンスまで手が回らないことが容易に想像できますから、小さな組織の開発においては、上述のような支持母体に関する指標を確認しておく方が好ましいでしょう。 以上が各軸の変数として筆者がよく検討するものたちです。 このように、筆者は普段の技術選定において、極力絶対的な評価をしやすい変数を利用するように心がけています。 組織開発の場合、その選択が説明可能 (Explainable) であること、が非常に大切だと考えているからです。 数字が具体的であればあるほど、その背後にある論理が明確であればあるほど、合意は形成しやすいものです。 「組織のかたち」 前項で検討した評価軸を支配する変数を眺めてみると、技術選択を評価するための軸は、組織に関する情報（組織規模、平均的な能力値、…）と強く結びついていそうだ、という示唆が得られます。 少し象徴的な表現をすると、技術選定は「組織のかたち」と強く紐づくものだ、ということです。 またこのような検討に鑑みると、巷にあふれる「ベストプラクティス」の類を咀嚼することなく自組織に導入していくのは好ましくない、と筆者は考えます。 その時の組織のかたちにをよく整理し、それに基づいて適切に評価を行った上で、自組織にはレガシーな開発手法がマッチすると考えるのであれば、それはそれでいいと思うのです。 逆に「バズワードだから」「楽しそうだから」に基づく技術選択も、その選択主体となる組織が、そういう行動規範を持っているのであれば、それはそれで組織のかたちとよく向き合えていると思います。いいんじゃないでしょうか。 まとめると、技術選定において大事なのは、「組織のかたち」に代表される諸変数を適切に洗い出し、そこから各評価軸についてを懇ろに検討した上で選択を下すことなのだろう、と思うのです。 余談: MVP とセキュリティ 少しだけ余談をば。 近年は Auth0 や Okta のような IDaaS（ID as a Service）の登場・発展や、Pomerium のような所謂 IAP（Identity-Aware Proxy）プロダクトの発展により、認証認可に関するコンポーネントを自作しないという選択肢 —— すなわち、技術選定の段階で認証認可を「前提」の中に据える、という選択肢が生まれてきています（といってもそこまで新しい話ではありませんが）。 またこのようなプロダクトの利用はどんどん簡単になってきています。 例えば GCP の場合、GCE/GAE をバックエンドとして L7LB を使っているのなら、それと一緒に Cloud IAP を有効化してやるだけで GSuite 組織を利用した AuthN / AuthZ が行えます。 これは非常に手軽ですが、社内向けに展開するアプリケーションの保護ならこの程度で十分でしょう。 Firebase を採用するなら、Firebase Authentication を使うのも一つの手です。 また SPA（Single Page Application）を作りたいのであれば、適当に Auth0 と契約し、auth0-spa-js を使ってやれば、あまりややこしいことを考えることなく AuthN / AuthZ を実装することができます。 簡単な RBAC であれば Auth0 サーバ上でスクリプトを走らせる機能（Rules や Hooks と呼ばれる機能）によっても実現することができます。 いまプロダクト開発初期のような、MVP（Minimum Viable Product）を作ることに注力したい時期においては、セキュリティについて考える頭のゆとりがあまりないものです。 むしろセキュリティ、というのは面倒な存在です。 そう考えると、このようなセキュリティに関する部分を「前提」の側に移せるように技術選定をする、というのは理にかなった方針なのではないかと思います。 サービス要件を担保しつつ、開発生産性を向上させることが期待でき、かつ一定技術信頼性の担保も（とくに有償のサービスであれば、サポートも含めて）期待できるからです。 勿論サービスの要件（例えば個人情報の取扱いに関する要件等）によっては、プロプライエタリなソフトウェアの利用が難しい場合もあるかもしれません。 しかし技術選択においてセキュリティ面の関心を分離しておくと、開発における「ややこしい点」「怖い点」を減らしやすいものです。 技術選定の際の選択肢の一つにするために、この辺りのソフトウェア・プロダクトを大まかに洗い出しておくといいかもしれません。 結びに 本稿においては、以下についての筆者の一連の考えを整理しました。 技術選定という営みがどのようなものとして整理できるのか その選定の結果の評価にはどのような評価軸を導入できるのか 各評価軸の背後にはどのような変数があるのか なお冒頭で述べたように、本稿はあくまでポエムです。 なのでこれが「ベストな技術選択の仕方だ！」というのを提示することはしません。 しかし読んでくださったあなたの頭の整理や、新たな気づきの源泉にならないとも限らないので、これを公開してみた次第です。 ところで、敬愛なる Rhymester さんの楽曲『The Choice Is Yours』（シングル『The Choice Is Yours』や他ベストアルバム等に収録されています）には、「そいつは自分たちの選択 マジ面倒 / だがそれもできないんじゃ もうジ・エンド」という一節があります。いい韻ですね。 いまこの曲は勿論技術選定についての曲ではありませんが、技術選択においても、同じことが言えると筆者は思っています。 技術選定は面倒な営みであるものの、他者の語るベストプラクティスを見て右へ倣えを続けるだけでは、道を踏み外しうるものです。 うまく参考にし、考え方を吸収し、あくまで自組織の選択として技術選定を行いたいものです。
0 notes
Last Seen Blogs
ceres-suggestions
Im A Thot For Grain
elysiumofnight
iris shishido
athena-minervaa-blog
Athena Minerva
jasongreyyy
Untitled
12woodenantlers
This is a thing