「ssh」を含む日記 RSS

はてなキーワード: sshとは

2022-08-11

anond:20220811153939

Webデザイン業者サイト構築を依頼して、SSHでのログイン方法も教えたけど

えすえすえいち?よくわかりません!って言われたのでわざわざその人のためにftpd入れました

2022-07-29

インターネット老人の基準って

色々考えられると思うが、俺なんかは

ネットニュース」と言われてNNTPの方を使ってた事を思い出せる世代ニュース配信ウェブサイトけが頭に浮かぶ世代

あたりで分けられそうじゃないかと思う。

リモートログインtelnetを平気で使えた世代ssh使わんとかキチガイだろって世代とかw

パソ通老人とインターネット老人は違う、みたいな話もあるけど、初期のネットユーザの多くはNiftyPC-VANあたりにアクセスしてた人間だし、"AOLer" みたいな「ネットアクセスするためにパソ通であるAOL契約」みたいなのが多かった訳で、専業プロバイダの高かったIIJとか、かなり安いけど怪しいベッコアメリムネットから繋いでパソ通サービス全然知らない「インターネット老人」ってどれくらい居るのよ? って思うんだけどな。 win95と同時に立ち上がったMSNだって最初パソ通サービス事業者だった訳だしな。

2022-06-24

もうね、ロードアベレージ50とかいくとね、sshがつながんないのよ

2022-02-20

今日日光がうざい

玄関のぞき穴に仕掛けてある防犯カメラの動体検知の誤検知率が高い。

日が照ったり曇ったりでいちいちアラートが届く。

sshログインして露出を下げるか。

2022-02-09

anond:20220209120631

ごめん書いてから気づいたわ

ラズパイ4はSSHトンネル張るだけの役割で、Guacmoleはクラウド運用してるのかもな

それなら理解

ビジネスとしても成立するわ

多段ルートになるから遅延が気になるが・・・

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2021-11-19

/etc/hostsとか/etc/ssh/known_hostsに

推しホスト名前とか書くのやめて

2021-11-11

なぜ人類プログラミングができないのか

プログラマは多いのに、プログラミングできる奴が少なすぎる。

まず、ひとつ言語簡単アルゴリズム実装できるだけでも、確実に自称プログラマの上位1%には入る。

もうこの時点で終わってる。加えて、

などの呆れるほど当たり前の要件をいくつか課すだけで、もう有名企業から引き抜きでもしない限り、そんな人材と巡り合うことは絶望的になる。

2021-08-31

anond:20210831013839

verbosity だ。ssh などのUNIXコマンドは実行時付加情報として -v が渡せるようになっていて、

デバッグなどの分析に役立つ情報を出してくれるようになる。

-vv,-vvv のように、v が増えるほど多くの情報を吐く。

2021-07-12

anond:20210712180031

タブがないのがつらくって。

ssh接続先1つにつき1タブとしてて接続先でtmuxを上げる運用にしているんだけど、Alacrittyで同じことをするためにはローカルtmuxの上で接続先でtmuxを上げる必要があって、それがどうにもついか自分には合わなかった。

2021-06-17

CTOだけど、一ヶ月Web就職レビューしてみた。

https://anond.hatelabo.jp/20210617075257

0. 温度感

基本的現在では、バックエンドフロントエンド運用保守全てができないエンジニア価値は無い。

経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。

典型的はてなー意識の高さ。

上がってるような基本(元増田に上がってるやつの倍ぐらい)が全部立ち上げからできて

2〜3個プロジェクト経験したらテックリード素養が既に身についてそう。

まり、ただのエンジニアにはそこまで要求されない。

プロジェクト的にもどっちかが弱いと

Rails/DjangojQuery+Bootstrapみたいな構成

Amplify/FirebaseにVue/Reactみたいな構成全然あるので

フロントバックエンドも一旦はどっちかでいい。

面接はなんとか抜けてもらうとして、

チーム開発での最低限の目標としては、

成果物から指導学習コストレビューコスト技術負債マネジメントコストを引いた分が正になっていれば

ひとまず「チームに居ていい人」と見なされそう。

チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、

一旦は、正の生産性を目指してほしい。

以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、

一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。

1. 言語: PythonJavascript

これだけで一ヶ月経つ気がするが正気か。

似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。

どっちかしかやらないならJavascriptおすすめ。後ででてくる、Flaskは適当Expressかに置き換える

現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。

どちらも、Python2とES2015以前の記法というレガシーネット上に転がってるので参考にしないように注意。

パッケージ管理単体テストタスクランナー

この辺は6のフロントフレームワークと同時にやる。

コードは断片的なサンプルではなく

一貫性があって

・正しい書き方がされた

お手本プロジェクトをなにか(github書籍など)で手に入れて読むべき。

おそらくフレームワークに乗っかっているので並行して進めることになる。

6. フロントエンドフレームワーク: Vue.js

話の流れで先にこっち

現在コーディングのグッドプラクティスデザインパターンフレームワークの形をしている。

なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。

とはいえ最低限としては使い方が分かるところまで。

TypescriptVue.jsも書き方をどこまで取り入れるかが使用者裁量に任されてるし、

開発でVueとReactのどっちを使うかはチーム次第なので、

一旦React+Typescriptガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。

2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。

パッケージとかテストタスクデプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。

2, 4. ツール: gitDocker

バージョン管理コンテナ思想が優れているのは自明なので、これらはツールと見ていい。

そして、後からプロジェクトに入った人がプロジェクト流儀に沿って使う分には難しいことはなさそう。

採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、

そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。

構築できる、ではなく、触れる程度で良さそう。

gitプロジェクト流儀によると書いたが、git-flowイメージ図を理解して運用できるのがよい。

https://qiita.com/KosukeSone/items/514dd24828b485c69a05

3. OS: Linux

これは「パソコンの使い方わかってますか」ぐらいの温度感

ファイルパーミッションユーザープロセスのような基本概念理解する

一冊読めば済むだろうし、概念系はさらっておいてほしい。

grepやfindやxargsなどのコマンドを組み合わせて簡単な処理を自動化する

こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。

sedとか正規表現も。

あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。

IPアドレスを調べたり、SSHリモートマシンログインする

地味にSSHログインした先の環境だと、vimが主要なテキストエディタになるので

vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。

ファイル開いて入力モードに切り替えて書き込んで保存して終了

チュートリアルする。拡張とかはいらない。

細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。

5. サーバーフレームワーク: Flask

フレームワークを覚えること自体重要なのではなく、Web開発の基本を習得することが重要

これが意図なら

HTTPルーティングデータベースSQL認証セッション管理などは当然すべて覚える。

この辺の機能を持った小規模Webアプリを作ってHerokuデプロイすれば一旦完成とみなしてよさそう。

コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい?

慣れると1日あればいけると思う。

フレームワークもなんでもいい。

軽量である必要もなくて、

Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。

余力があれば複数個触ってみたり、人から勧められたらそっちでも。

最近サーバーレス&NoSQL流行ってるのでFirebaseとかもやればいいと思う。

7. アルゴリズム

コメントリーが荒れててウケる

実務プログラミングで最低限必要アルゴリズム力は

「書いてるコード計算量オーダーを把握していること」

に尽きる。

計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて

O(n^2)やO(n^3)のロジックを書いてしまって

データ量が万〜十万の本番データで遅延するとか

それらに対して分散や非同期処理で解消しようとするとか、

ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為

アルゴリズム不要勢は平気でやるぐらい、両者は溝が深い。

計算量を意識するだけなら、AtCoderABCのC〜D問題辺りが解ければ十分。

8. セキュリティ

有名な脆弱性攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている

(XSS対策自動エスケープなど)

のでアドリブをせずに正しい書き方でやれば良い。

開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、

ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。

最後

開発の勉強のやり方としては、

・正しいコード見本を手に入れること

公式リファレンスを読むこと

エラーメッセージを読むこと(そしてググること)

この辺りの習慣があればやってけんのかな、

その他、チーム開発って面では

アジャイルサムライプロジェクト管理)とか

TeamGeek(人間性)とかインプットしておくと共通言語が増えて嬉しい。

この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、

そしたらやってけるんちゃうーって感じ。

経験から1ヶ月でWeb企業就職する勉強法

取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。

重要度が低いものは載せていない。たとえばHTMLCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。

逆に言えば以下に挙げる技術は、そもそも概念自体プログラミングにとって普遍的ものであり、(基礎的な部分を)調べながら使うようではエンジニア失格ということ。

基本的現在では、バックエンドフロントエンド運用保守全てができないエンジニア価値は無い。

以下に挙げた技術(①⑤⑥は他の言語フレームワーク代替可能)が身に付いていなければまともな企業就職することは難しい(もちろん、下らない業務システム下請けで作ってる底辺企業には入れるだろうが)。

経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。

特定言語フレームワークの書き方を知っていること自体意味は無い。

重要なのは、他の言語フレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。

PythonJavaScriptマスターする

この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。

プログラミング言語完璧理解する必要がある。

基本的な構文や、よく使う標準ライブラリは勿論、高階関数クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。

言語のみではなく、パッケージ管理単体テストタスクランナー等の周辺ツールの使い方も熟知している必要がある。

また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。


Gitの基本操作を覚える

Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、

等の基本的フローは必ずできなければならない。


Linuxの基本操作を覚える

多くの場合、本番環境テスト環境Linuxサーバーであるから、以下のような基本的概念と使い方を知っておく必要がある。


Dockerの基本操作を覚える

環境構築、CIデプロイなどは、現在コンテナを使って行うことが当たり前になっている。

これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。


⑤ Flaskを覚える

Flaskは、数あるWebフレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。

フレームワークを覚えること自体重要なのではなく、Web開発の基本を習得することが重要HTTPルーティングデータベースSQL認証セッション管理などは当然すべて覚える。

データベースは、就職したらMySQLPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。

作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。

追記 2021/06/17 14:07

ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式ドキュメントに従ってPostgreSQL使用して下さい。

SQLite3はファイルデータを持てる簡易DBなんだけど、Herokuデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。(DAOを丸ごと書き換える羽目になる)

参考: https://devcenter.heroku.com/ja/articles/sqlite3

ありがとうございます

Vue.jsを覚える

今の時代フロントエンドフレームワークなしで作るのはただのバカ

2021年現在実用的なフロントエンドフレームワークはReactとVueしかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。

フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVue完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。



基本的アルゴリズムを学ぶ

アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。

高速フーリエ変換のような高度な数学必要ないが、クイックソート木構造のような基本的アルゴリズムは当然、その性質を知っていなければならない。

それらは言語組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。

また、プログラムを読み書きする際には、そのコード計算量を見積もれなければならない。

セキュリティを学ぶ

セキュリティは言うまでもなく学ばなければならない。

有名な脆弱性攻撃手法XSSSQLインジェクション・CSRFなど)が何だか理解していて、その対策実装できなければならない。

各種暗号化技術署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性理解する必要がある。

認証パスワード管理などを実装する際は、当然ベストプラクティスに従わなければならない。

2021-05-31

anond:20210531125626

何日も前に書いた愚痴みたいなのに突然レスがついてビックリしたわ

まあ、X転送が厳しいってだけで、sshコンソール操作するのは全然問題ないで

anond:20210526223145

参考になる

SSHポートフォワードセキュリティ的にも経路的にも古くから使われてていいんだけど、

もうVPNしかポイントポイントっていうのが古臭く感じるようになってきてなあ

もちろん一般ユーザ的にはむしろ全盛期なイメージなんだろうけどな

2021-05-26

リモートワークしていると、インターネット越しにssh + X転送は遅いんやなって思うわ

時間帯によってはほぼ無理やな

2021-05-16

突然、紹介されるAndroidアプリ集を書いた増田ガジェット

こういうオープンソースとか詳しい人ってどんなスマホパソコン使ってんだろ?

気になるし資金的余裕があれば真似したい

anond:20210516133911

とのことなので暇だし書いてみる

パソコン

自作デスクトップパソコン
OSArch Linux
CPURyzen 9 5900X
ワーキングメモリ32GB DDR4 SDRAM
ストレージ(システム)1TB NVMe SSD
ストレージ(データ1)6TB SATA HDD(RAID0+1)
ストレージ(データ2)6TB SATA HDD(RAID0+1)
ストレージ(データ3)6TB SATA HDD(RAID0+1)
ストレージ(データ4)6TB SATA HDD(RAID0+1)
GPURadeon RX 6900 XT 16GB
ディスプレイモニタ(プライマリ)LG 35WN75C-B
ディスプレイモニタ(セカンダリ)中華ノーブランド14インチ16:9タッチスクリーンディスプレイ
キーボードLily58 Pro(黒軸)
トラックボールExpert Mouse K72359JP

AMD理由OpenGLを重視したか
データには主に子供写真動画が一杯入ってるので速度と冗長性を取ってHDD無駄使いしてる
タッチスクリーンディスプレイタッチスクリーン使うアプリ開発用でAliExpressから拾ってきたガワがない詳細不明品、3Dプリンタで作ったガワで無理矢理マウントアームに付けてる

ノートパソコン
ASUS Chromebook Flip C436FA
OSChrome OS
CPUCore i7-10510U
ワーキングメモリ16GB DDR4 SDRAM
ストレージ(システム+データ)512GB NVMe SSD
ディスプレイモニタ14インチFullHD

ノートパソコンではメインとなってるChromebook
実質的Android Appsが動くLinuxディストリビューションなので非常に便利
Chrome OS有用さを友人へ伝えるたび鼻で笑われていたが、コロナ禍でまさかの注目株に
Chrome OSを使ってる理由が、UNIX使いたい人が安定しているUNIXとしてmacOSを選ぶみたいなノリで、安定しているLinuxディストリビューションとしてChrome OSを使っていると理解してもらえれば良い
ちょっと突っ込んだ使い方しようとすると途端に意味不明挙動をするところまでmacOSと同じである

OneMix3 S+
OSChrome OS
CPUCore i3-10110Y
ワーキングメモリ8GB DDR4 SDRAM
ストレージ(システム+データ)512GB NVMe SSD
ディスプレイモニタ7インチFullHD+

Windows 10からChrome OSへ置き換えた我が家では実質的タブレットとして運用されているノートパソコン
ほぼ子供玩具で一緒にゲームしたりYoutubeみたり電子書籍を読むのに使われている
Chrome OSへ置き換えたのでAndroid Appsも動く

STB
NVIDIA SHIELD TV PRO
OSAndroid 10
CPUTegra X1+
ワーキングメモリ3GB DDR4 SDRAM
ストレージ1(システム+データ)16GB NVMe SSD
ストレージ2(システム+データ)1TB SATA HDD

日本ではほとんど注目されないスマートセットトップボックス
リビングTVYoutubeNetflixを観るのにこれ以上の選択肢はないのだが一般家庭にはあまり普及してないようだ
ちなみにゲームプレイできたりNAS接続できたりもする

スマートフォン

F(x)tec Pro1
OSAndroid 10
CPUSnapdragon 835
ワーキングメモリ6GB
ストレージ1(システム+データ)128GB
ディスプレイモニタ5.99インチFHD+
カメラ(フロント)8MP
カメラ(リア)16MP
バッテリー3,200mAh Li-ion
防水IPX67
生体認証指紋・顔
ICNFC A/B
充電USB-C・ワイヤレス
重量243g

メインで使ってるスマートフォン
ハードウェアQWERTYキーボードを搭載していてTermuxでsshするときに役立つ
スライド機構を搭載しておりQWERTYキーボードをシャコンとスライドさせて出せ、普段普通スマートフォンのように使える

Unihertz Titan
OSAndroid 10
CPUMediaTek Helio P60
ワーキングメモリ6GB
ストレージ1(システム+データ)128GB
ディスプレイモニタ4.6インチHD+
カメラ(フロント)8MP
カメラ(リア)16MP
バッテリー6,000mAh Li-ion
防水IPX67
生体認証指紋・顔
ICNFC A/B
充電USB-C・ワイヤレス
重量303g

サブで使ってるスマートフォン
ガジェット界隈では有名な鈍器で、iPad mini 2019が約300gだったことを考えれば鈍器と呼ばれる所以がわかる
バカバカしいスマホに思えるけど本来タフネススマホなので頑丈さに特化したからこその重さ
バッテリーが大容量なためモバイル無線LANルーター代わりで持ち歩いている
小型版のUnihertz Titan Pocketが予定されているけれどもちろん買う

Xperia 10
OSSailfishOS
CPUSnapdragon 690
ワーキングメモリ6GB
ストレージ1(システム+データ)128GB
ディスプレイモニタ6インチFHD+
カメラ(フロント)8MP
カメラ(リア1)12MP
カメラ(リア2)8MP
カメラ(リア3)8MP
バッテリー4,500mAh Li-ion
防水IPX67
生体認証指紋・顔
ICNFC A/B
充電USB-C
重量169g

お遊び、検証研究用のスマートフォン
最近スマホ一般的に普及しているものと異なるアスペクト比採用していることが増えてきてるのでTitanと合わせてアスペクト比確認用としても使う(アスペクト比が異なってても正しくレンダリングさせるの今後マジで必須だよ。アスペクト比の決め打ちイクナイ)
現在は一部界隈で注目されていたSailfishOSインストールされているが、ぶっちゃけオープンソースコミュニティ関連で人と会うときに見せるためだけに用意している

スマートウォッチ

THE CARLYLE HR SMARTWATCH(Gen 5) 44mm
OSWear OS
CPUSnapdragon Wear 3100
ワーキングメモリ1GB
ストレージ(システム+データ)8GB
ディスプレイモニタ1.28インチ
バッテリー310mAh Li-ion(1Day+)
防水IPX67(3気圧)
ICNFC A/B
充電独自
重量約50g(モデルにより異なる)

AndroidベースWear OSを搭載したApple Watch対抗のスマートウォッチ
美点はスタイリングデザイン豊富さと微妙Apple Watchよりもバッテリーの保ちが良いこと(使い方によって逆転できるレベルの違い、誤差レベルと言って良い)
AndroidChrome OSとの連携はさすがで、スマホを取り出さなくても使えるGoogle Assistantはスマート電球スマートSTB操作に便利
ただやはりApple Watchも抱えている問題でフル機能活用するとバッテリの保ちが1日+数時間というのは時計としてどうなんだろう
スマートウォッチが好きじゃないと毎日充電する気にはならないとは思う

Mi Smart Band 5
OS独自ファームウェア
CPUDialog DA14697 SoC
ワーキングメモリ512KB
ストレージ(システム+データ)16MB
ディスプレイモニタ1.1インチ
バッテリー125mAh Li-ion(14Day+)
防水IPX67(3気圧)
ICNFC A/B
充電独自
重量約12g

スマートウォッチの大本
安価でありながらスマートウォッチに求められることの大半が可能
大半の人にはMi Smart Band 5で十分、Apple WatchWear OSスマートウォッチは必要ないこと間違いなし
そろそろ新型のMi Smart Band 6が大陸以外でもリリースされる予定なので楽しみだ
万が一、億が一、Mi Smart Bandに機能不足を感じたらApple WatchWear OSスマートウォッチを検討しよう
Apple WatchWear OSスマートウォッチは自分のようなマニアポチポチして遊ぶような代物であって全くもってマニア以外にはオススメしない
ちなみに自分マニアなので左手首にTHE CARLYLE HR SMARTWATCH、右手首にMi Smart Band 5だ

という感じかな
増田投稿容量上限もあるのでこの辺にしとく

2021-05-08

anond:20210508204529

派遣時代派遣先のPCから自宅にsshトンネル掘って便利に使ってたけど派遣先がセキュリティ重視でいろいろ始めたタイミングでバレたな

始末書1枚で済んだのはまだまだ大らかな時代だった

2021-04-25

いわゆる「お金持ち」の家の子息が普段何をしているか

我が家明治期に興隆した商家で、現在も大枠を考えればモノやコトを売ることで生計をなしている。
いわゆる華族であったが、興隆の経過で江戸期以前の地主武家などと婚姻を経て結びついており、家系図を遡れば皇室とも血筋上の繋がりがあると解釈ができる。

さて、そんな家に生まれた筆者だが正直に言えば高校生くらいまで我が家がそんな家だとは気付いておらず、多少なりとも大きな家に住めている理由として両親や祖父母も「ご先祖様が努力の人だったから」と言っていたので、現在我が家はそこまでお金持ちではなくご先祖様が増やした資産恩恵を受けているのだ程度にしか思っていなかった。ご先祖様すげぇなと。
実際、筆者自身の子供の頃の夢はプロアーチャーであったので全く家業意識していなかった。

我が家はなんか他の家と違うぞ?と気付き始めたのは高校生になった時期で、父や祖父に連れられて社会科見学のような小旅行を頻繁にやるようになってからだった。
自動車工場や造船所、食品工場アパレル工場精密機器工場製紙工場など工業系を中心になぜか見学に連れられ、その工場担当者らしき壮年男性から説明を聞くということを頻繁にさせられた。
今思い出せば、父や祖父はそのくらいの時期から「AはBから生産されていて流通として……」のような話をよくしてくれるようになっていた。
社会科見学のような小旅行面白かったが、なぜ急にそんなことをやるようになったのかという疑問は晴れなかった。まさかそれが後継者教育の一環だったとは。

自分自身の興味と祖父の勧めもあり、大学ではアーチェリーを続けつつもロジスティクスを中心に学ばせてもらい、継続されていた社会科見学が非常に研究へ役立つようになっていた。
そして我が家歴史を完全に知ったのは大学3年生の正月に「就職はどうするのか?」と言われた際に「参考になるかはわからないが我が家家業説明しようか」のように教えられてからだった。
遡れば初代が江戸期に商家として暖簾分けを受け、現在まで続く家業の基盤を明治期に作ることができたとのこと。そこから登場する人名歴史の授業で習うような人々であり、まるで実感のなかった筆者は驚愕するしかなかった。

そんな家の子である筆者が普段何をしているのか?と言えば、某物流企業から商社を経て、現在は父から「そろそろ戻ってこい」と言われ、法人化している我が家の持ち企業へ務めさせていただいている。
筆者の専攻がロジスティクスなので新社会人の頃から数理的に物流計算するのが主な仕事で、笑ってしまうかも知れないが何処へ行くにもCASIO関数電卓ポケットへ入れている。現在関数電卓ソーラーパネル電池駆動するのでスマホなんかよりもよっぽど信頼度が高い。
弊社が集めたデータ取引からロジスティクスに関するデータを貰い、それを数理的に損益分岐点とのその確率をはじき出すというものだが、概算ではなく精密に計算する際はコンピューターに詳しい増田の皆様にも馴染み深いであろうAWSさくらを利用している。
ちなみに筆者のスマホAndroidiPhoneにはまともなターミナルがないので、ふと出先で大きな計算リソース必要になったときAWSSSHしにくい。まぁノートPC使えよって話だが。

もちろん計算するだけでなく、創作物イメージされやすいであろう会食などで人脈交流をしたりもするが、実際のところ筆者の世代ともなるとLINEZoomSlackなどで友人たちと交流している頻度のほうが多い。
正直LINEZoomは昨今の流れもあり使いたくないのだが友人たちは経営学部卒などの文系が多いので、どうもセキュアなコミュニケーションツール活用が上手く行かない。
可能ならば弊社で利用しているオフィススイートMicrosoft office 365やGoogle Workspaceへ移行したいのだが、一部の従業員の皆様の反発から上手く行ってない。後継者といっても実務へ強権を奮えるほど実力はないのだ。筆者の管轄研究グループは即座にSlackを導入できたり出来たのに。う〜む……。
流れのまま愚痴を言えば、例えば総務などはミドルハイエンド性能なChromebookで十分じゃないか?社内ツールもいつまでJavaベースのを使っているのか。HTML5ベースに移行してしまえば互換性の問題Windows使い続ける理由もないんだが。いまだ動いてる骨董品メインフレームをそろそろ引退させてあげようよ。
父は「実務に口を出すべきでない」と言うが、多少筆者の趣味も入ってはいもの環境を整えるのも我々の役目ではないだろうか。
強権を奮って一気にモダンコンピューティング環境にしたい。営業にも今のガラケーから最新のGoogle Pixel 5あたりのスマホを配ってあげるのに。

というようなことを青臭く思っているのだが、実際の後継者なんてこんなもんである。実権を握れるまでおとなしくしているしか無い。
従業員の皆様には申し訳ないが、おそらく筆者にはご先祖様ほどの商才は無いんだろう。苦労させてごめんね。

2021-03-13

フタ閉じてるノートPCLAN経由でログインできないので不便

原因としては「ノートPCを閉じてると"スリープ"する」という一点に集約される

なので、「フタ閉じてもスリープにしない」という設定にしてデスクトップを表示している状態でフタ閉じてSSH使うとコンソールログインができる

リモートデスクトップできると便利かなと思うのだが、ノートでXログインしてる最中リモートデスクトップそもそも使えない

Xのログイン待ち画面で「フタ閉じてもスリープにしない」という設定をつけられればいちばんいいのだが、

…いや、なんかごく普通につけれそうな気がするが、GUIでは項目なさそうで調べるの面倒そうだし、なんか別なとこに影響してもちょっとイヤだ

いっそあれか、ノートPCで「フタ閉じてもスリープにしないという設定にしてるだけの一般ユーザー」をひとつ作ってそのデスクトップ画面をずっとノート本体に表示させようか

あー、それでいいかな…うまくいくかな…

2020-12-21

anond:20201221171436

https://qiita.com/satto_sann/items/9d95241af81dc4466ee1

こっちは昔参考にした。難易度高すぎ。この辺のブログを片っ端からみてSSH+WSLでもできるようになったけど毎回認証させられる不便さは残った。

2020-08-23

プログラミング初心者macをわざわざすすめるバカについて

タイトル通りなんだが、

mac プログラミング 初心者」とかググると、

初心者にはmacおすすめ!」「世の中のプログラマはみんなmac使っている!」

というバカなことを言っているアホが仰山いて笑える。

しかも、最近OS事情が大きく変わっているのに、未だにwindowsunixコマンドガーとか言っているやつが居る。もうね、言葉を失うよね。

まず、最近のOS事情の移り変わりなんだけども、windows最近かなりLinuxに近い触感になるような機能が多く追加され続けている。

例えば、wsl(コマンド関係)やwinget(CUIインストール)が挙げられる。

他にそれらを取り巻くプログラミング事情としては、vscodeがある。vscodeは、powershellsshだけでなく、wslのコマンドも使えるようになっている。

そのため、従来はpythonやらjsはめんどくさ。とおもっていた点もある程度は改善されている。

ちなみにmac特に最近プログラミングに関する話を聞かない。

自分が、プログラミング環境の次に、大事な要点だと思っているのが、一般人使用含めたシェア率。

正直、作っても誰にも使ってもらえないという状況では、全く意味がないので、シェア率は非常に大事だと思っている。

最近データでは、88%ぐらいがwindowsであるという統計がある。web系やiosアプリならまだしも、パソコン一般人に使わせたいソフト(特にゲームとか)を作りたいなら、windowsしか選択肢ないと思う。

そんなわけで、元からmac使いなら、まだしもわざわざwindowsから乗り換える必要は全くない。

ただ、mac使いでも全くwindowsでないと非常に困るということは、ある程度は…無くなってきてはいるですよねー。

ほれ、クロスプラットフォーム開発が盛んで、ライブラリなどの環境から障害は、少なくなってきているので…ただし、ios開発お前だけは許さない。

本題から外れるが、2点ほど、釘差したいだけども。

1点目は、webからプログラミング始めたいとかいう奴に釘差したい、

web系はある程度セキュリティやらデータベース、コマンド知識やらないと爆死する。そんなわけで、GUIオンリーパソコンを楽しんできた奴には、マジでお勧めしない。

まずは、webからではなく、統合開発環境上で実行ファイル(メモ帳とか)を作れる方面から始めろ。そして、linuxとかネットワークとかセキュリティとかの本を片っ端から読め。webを始めるのは、それからだ。

webでも実行ファイルを作ることは、星の数ほどあるし、別に必要ない知識はないぞ。

2点目は、勉強とはいえ、いつも使っているOS上で、コマンドが使えるからと鯖建てるな。(windowsmacどちらも)

かならず、仮想OSでやれよ。ミスって、apacheインストールできないとか言われても、周りは困る。とりあえず、わけわかめになったら、スナップショットリセットしとけ。

ログイン ユーザー登録
ようこそ ゲスト さん