あとで読むに関するmiho-satoh-satomiのブックマーク (161)

  • Ubuntu 22.04 をインストールしたら設定すること 10 ヶ条

    2023/04/29: これくらいの情報はググればすぐに出てくると思いいったん非公開にしましたが、意外とそうでもなかったので自分用メモとして再公開しました。 1. ソフトウェアのダウンロード元を変更してシステムをアップデートする (*) Super キー(= Windows キー)を押して、software と入力し、「ソフトウェアとアップデート」を選択します。 「設定...」ボタンを押して、「Ubuntu のソフトウェア」タブの「ダウンロード元:」から ftp.jaist.ac.jp などの国内ミラーサーバーを選択します。 アップデートが存在する場合は、表示されるウィンドウの指示にしたがってパッケージを更新し、Ubuntu を再起動します。 2. キーボードの CapsLock キーを Control へ置き換える /etc/default/keyboard を編集します。

    Ubuntu 22.04 をインストールしたら設定すること 10 ヶ条
  • 「引っ越しするけど会社から歩いて10分圏内ってどこまで?」を調べるサービスをつくりました

    こうです。 新しい住居を探そうとしたとき、「会社から歩いてちょうど 30 分のところに住めたら QOL 高くない?」と思いました。(運動できる、公共交通機関と無縁、買い物もできるetc...) でも ある一点を中心とした移動可能エリアを知りたいとき、円でざっくりと表示をする以外のアプローチがほぼない ことに気がつきました。海外サイトも含めかなり調べてみましたが、類似のサービスは見当たりません。 という経緯でつくったのが How far can I go? というサイト。 ぽちぽちやっていただければわかりますが、結果の精度はかなりのものと思われます。特に道の有無や川沿いなどを検証してもらえるとその効果がすぐにわかるかと。 転職先が決まっているなら、そこにピンを差して交通手段と所要時間を設定してください。HOME'S などの住宅検索サービスには条件絞り込みをしたあとにそれらを地図上にまとめてマ

    「引っ越しするけど会社から歩いて10分圏内ってどこまで?」を調べるサービスをつくりました
  • ITエンジニアの年収と責務の関係について体験交えて解説していくか|しのゆ

    Photo by Giorgio Trovato on Unsplash 年収800万は普通のエンジニアか否か。火種はいつものTwitterでしたが、いろんな意見が飛び交う興味深い話に各所でなっていたようですね。うーん、様式美。 ちなみに私の感覚だとこんな感じで、年収800万といえば、一般的なWEB開発においては複数プロジェクト技術設計を行うアーキテクト級で、SIerではおそらく課長-部長級の給与になると思っております。年収800万はそういうラインです。 年収340 → 新卒 年収400 → 2年目(転職サイトゴロゴロ 年収500 → 普通のエンジニア 年収800 → アーキテクト、テックリード 年収1000 → PM、一部スタートアップエンジニア 私の感覚だとこれですね https://t.co/1bXuiPexRj — shinoyu (@shinoyu) February 9, 2

    ITエンジニアの年収と責務の関係について体験交えて解説していくか|しのゆ
  • とりあえずWebサービス作る時の私の技術選定ポイント@2022/02

    はじめに inspired mogaさんのブラウザで動くサービスを作るときの技術選定が素晴らしい記事だったので、自分も書いてみる事にしました。 幸いにも技術選定からのお仕事をする機会が多くて、自分の中でパターンが大体決まってきているので言語化してみます。前提が同じサービスは無いので絶対的な正解は無いですが、なんかしらの参考になれば幸いです。 ※2022/02時点 私/よくあるお仕事について Web系のサービスなんかいい感じにするマンとして、フリーランスとして働いています。 準委任という形でスタートアップ企業をお手伝いする事が多いです。 MVPを作りたい、もしくはMVPは行けたのでちゃんと作り直したい、という要望があって参画して、まるっと作ってそのまま運用をします。作って終わりではなくて、運用や拡張性を考えてやってます(サービスに必要なのはもちろん、運用する自分が楽だから)。 前提 エンジニ

    とりあえずWebサービス作る時の私の技術選定ポイント@2022/02
  • 中小企業でApple製品を利用する前にやっておくこと

    はじめに 企業でApple製品を利用したいというニーズは昨今とても多くなってきていると思います。 しかもApple製品は買えばすぐに使えてしまうというメリットでもあり、企業としては情報統制という意味でデメリットとなります。 またゆるく使い始めてしまうと、後々企業できちんと管理する場合にとても面倒な事になります。 この記事では、今後Apple製品を利用しようとしている中小企業の情シス担当者向けに、事前準備として実施しておいた方がよいことをまとめます。 こんな企業にお勧め スタートアップ これからApple製品を使い始める予定があるけど、よくわかってない 実はもう使っちゃってるけど、心配。。。 やっておく事リスト appleの営業担当と繋がる AppleStoreForBusinessの設定 ABM(AppleBusinessManager)の設定 Appleの営業担当と繋がる 何をするにもま

    中小企業でApple製品を利用する前にやっておくこと
  • 日記駆動仕事術のススメ | DevelopersIO

    仕事日記を書くといいですよ」という話をする機会があったので、日々の仕事をスムーズにするシンプルな「日記駆動仕事術」について書いてみました。 日記書くといいですよ prismatix事業部の塩谷(@kwappa)です。 他部署の人と1on1する機会があり、その中で「日記書くといいですよ」という話をしました。 そういえば以前からことあるごとに「日記書きましょう」と言い続けていたのですが、ちゃんとコンテンツにしたことはなかったような気がします。 せっかくの機会なので、日記駆動の仕事術とその意義について書いてみます。 日記駆動仕事術 これはぼくの1月の日記(架空)です。Notionを使って、1か月に1ページ使うようにしています。やり方はシンプルなので、手に馴染んだツールで置き換えることも簡単だと思います。 タイムラインとしては、1/31(月)の業務を開始したところ、だと思ってください。 TODO

    日記駆動仕事術のススメ | DevelopersIO
  • コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ

    用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか? ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか? Pull R

    コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
  • Reactベストプラクティスの宝庫!「bulletproof-react」が勉強になりすぎる件

    Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 ※2022年11月追記 記事リリースから1年ほど経過して、新しく出てきた情報や考え方を盛り込んだ続編記事を書いていただいているので、こちらも併せて読んでいただければと想います(@t_keshiさんありがとうございます!)。 ディレクトリ構造が勉強になる まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 ソースコードはsrc以下に入れる bulletproof-reactでは、Reactに関するソースコードはsrcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリにcomponentsやutilsといったディレクトリはありません。 たとえばCreate Next Appで作成

    Reactベストプラクティスの宝庫!「bulletproof-react」が勉強になりすぎる件
  • 60億円の損害を出した 「DMMブックス」 70%OFFキャンペーンでプラットフォームに何が起きていたか

    ログ基盤をCloudWatchLogからNewRelic Logs + S3に変えたら 利便性も上がってコストも下がった話

    60億円の損害を出した 「DMMブックス」 70%OFFキャンペーンでプラットフォームに何が起きていたか
  • FlutterでWindows用のアプリを作成する | CyberAgent Developers Blog

    自己紹介 現在、株式会社MG-DXにて、Webフロントエンドエンジニアをやっている植木といいます。一つ前のプロジェクトはOPENRECでiOSエンジニア、その前は、ピグでUnityエンジニアをしていました。ネイティブアプリを作るのが好きです。MG-DXでは薬急便というオンライン診療・服薬指導がWebだけで行えるサービスを提供しています。新たにアプリをインストールしなくても、SafariやChromeだけで気軽に使えます。 開発の経緯 薬急便は、患者向け、医療機関向けに展開しています。患者から予約が入った場合に、医療機関にはメールやFAXが通知されるようになっています。FAXでは、受信するまでの時間や画質の低下が気になり、コストもかかるので、代替手段で、Webから印刷機能を提供する話が出てきました。 キオスクモードでの印刷や常駐アプリとWebで連携して印刷する海外のアプリもありましたが一長

    FlutterでWindows用のアプリを作成する | CyberAgent Developers Blog
  • 「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete

    このビデオについて このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こし はじめに 目次 記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介 Au

    「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete
  • なぜ組織の透明性が大切なのか - 30歳からのプログラミング

    個人的に、組織の透明性というものに関心を持っている。自分にとって大切なことだし、組織にとっても大切だと思っている。 この記事では、透明性に対する現時点での考えを書いていく。今の自分の頭のなかのスナップショットのようなものなので、あまり整理されていない。 大きく分けて、なぜ透明性が大切なのか、そして透明性を実現するために大切だと思っていることについて、書いていく。 透明性とは何か、透明性が高いとは具体的にどういう状況のことなのか、といった話は扱わない。取り敢えず、情報や意思決定のプロセスがオープンになっており誰でも制限なくアクセスできる、くらいの意味で書いている。当はそれだけでは不十分で、情報のメンテナンスやサマライズ、適切な通知やアナウンス、なども必要になってくるが。 なぜ透明性が大切なのか 透明性に問題があると何が起こるのか、という角度から述べていく。 モチベーションが下がる もしかし

    なぜ組織の透明性が大切なのか - 30歳からのプログラミング
  • テスト優先度をあげたくなる実話 - フロントエンド版 -

    Storybook・テストに関して「メンテナンス工数に見合うだけのメリットがあるか?」という議論を、経験したことはないでしょうか。フロントエンドは、とにかく動くものを作ることが優先され、Storybook・テストが二の次になっている現場も少なくないと思います。 限りある工数を割きチームで取り組むものですから、導入するためには「どういったメリットがあるのか?」という具体的な例をチームに示す必要があります。これは今年、筆者が体験した実メリットのお話です。導入を躊躇している現場にむけ、参考になればと思い書きました。 【Storybook】不要な Global CSS を削除できた きちんとコンポーネント設計され、コンポーネントに閉じた指定をしていたとしても、どこかに必ず Global な CSS があると思います。何かしらの資材を受け継ぎ立ち上げたプロジェクトに関しては、Global な CSS

    テスト優先度をあげたくなる実話 - フロントエンド版 -
  • Netflixにおける実用的なAPI設計: gRPCとFieldMask | pyspa

    Netflix Tech BlogのgRPC APIに関する以下の2つの記事に感銘を受けたので、ここにその概要を日語で記します。 (めんどくさかったので)翻訳の許可は取ってませんが、再構成してますし元のJavaではなくPythonで書き直していますので、容赦して下さい… Practical API Design at Netflix, Part 1: Using Protobuf FieldMaskPractical API Design at Netflix, Part 2: Protobuf FieldMask for Mutation OperationsまとめgRPCでは、FieldMaskをうまく使うことで、必要な情報だけ取得したりあるいは与えたりしたりできまっせ第一部まずField Maskをどのように使うかを述べています。 背景Remote Callというものは、そもそもコ

    Netflixにおける実用的なAPI設計: gRPCとFieldMask | pyspa
  • リーダブルなコードを書く習慣の身に付け方・実践の仕方 - 2021-09-22 - ククログ

    結城です。 2021年9月13日から14日にかけて、東京都立大学の大学院生向け特別講義として「リーダブルコード演習」を実施しました。 演習の内容は、当社でこれまでにも行ってきているリーダブルコードワークショップを、プログラミング経験が比較的浅い・プログラミングの量がまだそれほど多くない方向けに調整した内容としました。 この記事では、実施した演習の概要と、今回意識した点を紹介します。 文が長いため、目次を用意してみました。 発端 演習の構成 座学パート リーダブルなコードを書く意義について リーダブルコードを実践するためにまず取り組むべきこと 実際の現場での「コードがリーダブルでなくなってしまった」「リーダブルになるよう改めた」実践例 最初の実装 リーダブルでなくなった実装 リーダブルさを取り戻すための改修 コードがリーダブルでなくなっていってしまう要因 壊すのが怖くて、見て見ぬフリ 恐怖

    リーダブルなコードを書く習慣の身に付け方・実践の仕方 - 2021-09-22 - ククログ
  • 元米マイクロソフト本社パワポ責任者が教える「科学的に正しい資料の作り方」- Schoo PENCIL

    営業資料、マーケティング資料など、社会人によって資料作成の能力は必須スキルといっても過言ではありません。 はたして、みなさんの資料作りは“科学的に正しい”方法で制作されているでしょうか? 株式会社クロスリバー社長・株式会社キャスター事業責任者で、これまで1万人以上に資料作成術をレクチャーしてきた越川慎司先生は、ヒアリング調査やAIによる分析を用いて伝わる資料の作り方を分析し、『科学的に正しいずるい資料作成術』を著しました。米マイクロソフト社でパワポなどの責任者としても活躍していた越川先生の知見は、あなたの資料の作り方をがらりと変えてくれるはずです。 授業の前半である今回は、「わかりやすいスライド」とは何かのレクチャーや伝わる資料と伝わらない資料の比較など基礎的な内容となっています。

    元米マイクロソフト本社パワポ責任者が教える「科学的に正しい資料の作り方」- Schoo PENCIL
  • マイクロサービスに次に来るかもしれない言葉について - arclamp

    2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て

    マイクロサービスに次に来るかもしれない言葉について - arclamp
  • クリーンなReactプロジェクトの21のベストプラクティス - Qiita

    コード品質向上のための実践的アドバイス Photo by Diana Polekhina on Unsplash. はじめに Reactは、構成の方法について特に決まりがありません。まさにこれが理由で、プロジェクトをクリーンで保守可能な状態に保つことは、私たちの責任なのです。 今日は、Reactアプリケーションの状態を改善するために従うべきベストプラクティスについて説明します。これらのルールは広く受け入れられているため、この知識を持つことは必須です。 すべてコードで示します。さあ始めましょう! 1. JSXの省略形を使用する ブール変数の受け渡しには、JSXの省略形を使うようにしましょう。例えば、Navbarコンポーネントのタイトルの可視性を制御するとします。 悪い例

    クリーンなReactプロジェクトの21のベストプラクティス - Qiita
  • macOSでもWSLみたいなLinux環境を手に入れる - Qiita

    macOSでもLinuxの仮想環境が欲しい時はある Dockerを利用するなど、macOSであってもLinux環境が欲しい時はあります。 Microsoft365や、Adobe CCなど、macOSWindowsでしか使えないプロプライエタリなソフトウェアを使う、開発もほとんどの場合macOSネイティブで問題ない、でもDockerも使う、などのように主たる作業はmacOSでやりながらLinuxもちょっと使わないといけないということは多々あります。 VirtualBoxなどを利用することによって、仮想環境にLinuxをインストールし利用することはできますが、WindowsにおけるWSL (Windows Subsystem for Linux) のようにネットワークやファイルシステムが統合されたように見える環境を構築するのは面倒です。 そこで、"macOS subsystem for Li

    macOSでもWSLみたいなLinux環境を手に入れる - Qiita
  • シェルスクリプトを書くのをやめる - blog.8-p.info

    今年から、できるだけシェルスクリプトを書くのをやめようとしている。私が毎日 zsh に打ち込んでいるのも広義のシェルスクリプトだし、自分用の雑なスクリプトを書くことはあるけれど、チームの他の人も将来に使ったり改変したりするようなものは、なるだけ他の言語を使っている。 シェルスクリプトを書くのは難しいし、その難しさは、学ぶに値しないといったら言い過ぎかもしれないけれど、2021年に初心者が取り組むべき問題とは言い難いと思う。 シェルは悪いプログラミング言語である Bash Strict Mode とかを使ってみても、シェルスクリプトには落とし穴が多すぎる。自分で書いたものを自分で使っている分には大丈夫なのだけど、スクリプトがチーム内で使われるようになると、考慮していなかったところ、例えばファイル名に空白文字が含まれるとか、そういうレベルの微妙なところで、ちゃんと書かれていないスクリプトは壊れ