  |
はてなキーワード: MACOSとは
以下、ボクの考えた最強の iPad Pro
強化されたタッチパネルにより、どんな金属芯のプラスチック棒も Apple Pencil 2 並みの入力デバイスに変わります。
最新の AI技術を iPad でも。オープンな自動画像生成の力をあなたの仕事に取り入れましょう。
熟練のプロにさらなる力を。すべての UI アニメーションを短くして、あらゆる操作が魔法のように素早く。
Thunderbolt4 で接続すれば、あなたの許可で、iPad を外部ディスプレイに変えられます。
接続したコンピュータから一般のストレージのように自由にアクセスできます。
iOS subsystem for Linux の登場です。歴史ある GNU/Linux のユーティリティをオーバーヘッドなしで利用しましょう。
指に馴染んだ USBキーボードが、最新技術で生まれ変わります。
今年の新しい iPad はありません。その代わり、従来のiPadが＄200 安くなりました。
まったく新しいワンチップコンピュータ apple chip は iOS の基本部分が動きます。＄10 です。最先端の技術と一緒に、電子工作の世界を探索しましょう。
タイトル通り。
彼女いない歴=人生かつ女の子と手を繋いだこともデートした事もない純粋童貞だ。最近では特に珍しくない普通の人間です。
そんな純粋童貞を代表して問わせてもらうと、恋愛の何が素晴らしいかが不明ということです。
違和感は小学校の教科書で説明を読んだときからあった。説明を読んでも実感としてピンと来ないんだ。恋愛もひょっとして自己啓発本を売るための口実なんじゃないかってくらい、感覚的に理解できない。
ちなオタクでもあるので、より一層の解らなさが募る。
だって、本当にそれが素晴らしい趣味なら、誰かが布教活動するハズじゃないですか。
こちとらVtuber もアニメもSFもmacOSも自作キーボードも、それぞれで沼ったジャンルを推してきたんですよ。
カタギの人にも良さみが理解できるように、解説記事を書いたり宣伝活動をしてきた。
はてな匿名ダイアリーでも、推し増田、お馴染みでしょ？
なのに、恋愛のススメ、という内容の記事は一切見たことがないよね。
これって恋愛が特に人生において重要ではない、“客観的証拠” だと思う。
お気持ちの非難・対人論法の罵倒では破壊不能な “客観的証拠” がここにある。
タバコやパチンコ、ソシャゲ、お酒にも縁遠い人生を送ってきた。
付き合いで酒くらいは飲むけれど、一人で飲んでもドーパミンは放出されない。
同じように、恋愛もしない。今までは人生の欠損のように思っていたけど、よく考えると逆だ。
恋愛をしない事で他のよりコスパのいい趣味に可処分時間を注げるんだ。
僕らって実は——…恵まれてる。
付属のディスクの多くはMac環境に対し「Mac標準（HFS）」形式で
制作されており、2016年にリリースされたMac用OS「macOS 10.12 Sierra」より
「Mac OS標準フォーマット（HFS）」のサポートを終了したため、そのままではこの形式のディスクが読み込めなくなったそうです。
昔買った素材集DVDとか必要だったので取り込もうと思ってできなくてググった結果こういうことみたい
こんなことなら買ってすぐHDDとかに入れときゃよかったわ・・・
1500円にしてはとても満足できた作品。
https://www.dlsite.com/pro/work/=/product_id/VJ013196.html
インストール手順
https://github.com/Gcenx/WineskinServerの手順に従う
64bit版のWS11WineCX64Bit21.2.0だと、次のwmp9のインストールが上手くいかない
fakejapaneseは日本語フォント、wmp9はゲーム内ムービー再生に必要
全ユーザー対象でProgram Files以下に入れる方が楽
レイヤー以外の選択肢ではムービー中に音楽は鳴るものの画面は真っ暗になった。
Wineは大変便利、M1チップだがRosetta2のおかげで速度も全く問題ない。他のゲームでも参考になればと思い書いた（Twitterにはエロ書けない）。
Appleお前なぁ・・・学習コスト高すぎんだよ！！！！！
ナンチャラKitとかよぅ・・・イノベーティブだって！？Appleデバイスでしか使えないやんけ！！！！！
VulkanとかFlutterとかのほうが話題になっちゃってる現状を見ろよ！！！！！
何故かわかるか！？
VulkanとかFlutterはほかのプラットフォームでも使えるからなんだよ！！！！！
お前どうせDirect3Dみたいな立場を夢見てんだろ！！！！！
macOSのゲーム環境がウンコなのDirectXのせいだろ！！！！！
なんでマイクソソフトの真似しようとしてんだよ！！！！！
Flutterが流行の兆しを見せたからってやっつけでSwiftUIなんて作りやがって！
そういう仕事するからSwift(SwiftUI)は未完成とかって言われるんだぞ！！！！！
いまだUI Kit使われてるのはそういうことやぞ！！！！！
WindowsのWSL2がそこそこ使えるLinux環境整備しちゃって開発者みんなWindowsだLinuxだと言い始めてる現状をマジで直視しろよ！！！
これでQualcommがまともに使えるラップトップ向けSoCでもリリースしてみろ！
M1のマイナーチェンジのくせにメジャーナンバー上げてマーケティングで劇的性能アップなイメージ振りまいてる場合じゃなくなるぞ！！！！！
ブランディングネームなんてお前の胸先三寸だってバレてんだよ！！！！！
Apple信者！いまのAppleの開発環境の学習コスト高すぎてマジで微妙だってのは知ってくれ！！！！！
そのコストを負っているのは開発者でWindowsやLinux、Android界隈がクロスプラットフォームを強化していて眩しく見え始めていることを認識してくれ！！！！！
Apple信者お前らだけがAppleの目を覚まさせられるんだ！！！！！
もう書いている内容の時点でエンジニアに既に向いてないじゃん
でも向いてなくてもなんとなく食っていけるのがIT業界のいいところよな
Macを推奨するサイト（ブログ）が多いが…
数量的にきちんと把握したものではないですが、「プログラミングに向くPCはMac」（特にMacBook）という解説のサイトは多く見つかりますが、大抵はプログラミングスクールが制作した集客用ページ、フリーランス（ブロガー）による広告収益目的のページで、制作の意図には商業的な目的がありそうです。
「エンジニアはMacを使用している」という主張もありますが、実はこれは根拠がありません。
ITエンジニアがWindowsとMacどちらをよく使用しているかを調査した統計は見つかりませんが、エンジニアに限らず、一般的にどちらが使用されているかを示すデータならあります。情報処理推進機構がインターネット利用者の使用OSを調査したものですが、圧倒的にWindowsです。macOSはたった4.3%です。数年前とは言え、状況は劇的には変化していないでしょう。
Windows7 (21.9%)
明確な根拠がない以上、主観の域を出ませんので、安易に信用はできません。
私見ですが、MacBookを推奨するサイトが多い理由の1つは「おしゃれでウケが良いから」です。twitter上の駆け出しエンジニア（もしくはエンジニア志望）の方々を見ると、大抵、見た目がきらびやかなものに飛びつく傾向があるので、その点、MacBookはウケやすそうです。まぁ、スタバに座ってMacBookで仕事をすれば確かにおしゃれです。
Google AdSenseを収益源にするサイトは閲覧数が重要なため「どのような記事なら見られるか」から逆算して考えます。なので、必然的に見た目の格好良さが重視されます。これは、SEOとかWebライティングと呼ばれる技術の悪い側面ですね。
ちなみに、私もMac（MacBook Pro）を1台所有していますが、購入のきっかけは勉強のためでした（色んな機械を触ってみたいから）。Macは特にメイン機ではありません。開発環境がWindowsにもあるので、両方を使用しています。
「Macはプログラミングに向いている」は本当か？
複数のプログラミングスクールのサイトで「MacはRuby、Python、PHPは特に開発効率が良い」という解説も見つかりますが、理由が説明されておらず根拠がありません。
WindowsだとVisual Studio Codeという非常に強力なエディタが無料で使用できるし、テキストエディタのAtomもプラグインを入れれば、それなりに開発はできます（ちなみに両者はMac版もある）。後で解説しますが、Web系がメインのエンジニアであればmacOSは親和性は高いのは事実ですが、だからと言ってWindowsの開発効率が悪いことはないです。
それに、Python、Rubyは今後はデフォルトではmacOSには含まれなくなります
https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes
プログラミングPCにWindowsとMacどちらを選べばよいか、という問題 | YukiPress
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。
弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。
気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindowsしか選択肢ないでしょうしね。
ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ？」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。
いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。
どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。
これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。
Linux環境では苦手なIllustratorのAI形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。
開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUIクライアントはGitKrakenです。
入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや？を理解している状態にあります。
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。
社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。
プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。
他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。
ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。
会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます。
残り5%は主に私が出社しているからｗ
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね？週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろｗ
結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも？
1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
RStudioがPC内から気がついたら消滅していたので何回もやり直すのが面倒で書いた
コメントアウトをいじればFedoraやmacOSでも動くと思う
https://pastebin.com/HiPqLVq7 (6/4 shコマンドでも動くように修正 以前はbash hogehoge起動していたので動作確認していなかった)
エラーでここに貼れなかった
util-linux(rev) libxml2-utils(xmllint) gpg curl coreutils(sha256sum)とR関連
echo "$HTML" | xmllint --nowarning --xpath hogehoge --html - | hogehoge
こうしないとxmllintがエラーでhtlmなどをうまく読み取らない
sed 's/href="//g;s/"//g;s/\s/\n/g;s/^.?$//g;s/^\n//g'
href="hogehoge"の形で出てxmllint内で除去出来なかったのでsedで妥協
hrefが1回しか出ないのでひとまとめにできそうだが面倒なので分けた
この書き方なら複数回出ても除去できるはず
先頭の謎のスペースの除去が面倒だった
echo "$HASH" "$FIELNAME" | sha256sum --status -c ;echo $?
スペースが2つないと書式で怒れられてハッシュ値が合っていてもsha256sumが終了ステータス0で正常終了を返してくれない
VScodium
ShellCheck
https://open-vsx.org/vscode/item?itemName=timonwong.shellcheck
XPath Helper
https://chrome.google.com/webstore/detail/xpath-helper/hgimnogjllphhhkhlmebbmlgjoejdpjl
zenn.devに書こうか迷ったがどちらの方が良かったのだろうか…
ダウンロードしたサーバーがやられてるならハッシュ値も改ざんするだろうgpgで確認しないと意味ないでしょとかsudoでやったらディレクトリがとか色々ガバあるから誰かいい感じに改良して
https://cran.rstudio.com/bin/linux/debian/
https://www.rstudio.com/code-signing/
