ソフトウェアはなぜバージョンアップしなければならないのか - Qiita
はじめに 社内インフラの運用担当者にとってソフトウェアのバージョンアップは地味な割に大変な業務です。 特に社内のオンプレサーバで動いているようなソフトウェアの場合、バージョンアップに伴う諸々の調整をそのソフトウェアを利用している各部署と行う必要があります。 そんなときに「今は忙しいからバージョンアップを先送りしてほしい」「このバージョンはスキップしてもよいのでは？」なんて声が各部署から聞こえてきます。バージョンアップの価値を各部署に理解してもらうのは大変です。 この文章はそんな時になぜバージョンアップしなければならないのかを上司や各部署のマネージャに伝えるために書きます。 ソフトウェアの有効期限は2-5年 まず、第一に、ソフトウェアというものは無限に使えるわけではなく、一定の有効期限があり、それを過ぎると徐々に動かなくなってきます。俗にいう「何もしてないのに動かなくなった問題」です。 なぜ
フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか - Qiita
ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April
「技術書の読書術」を読んだら読書効率が上がったので感想&サマリ抜粋 - Qiita
「技術書の読書術」を読みました 「技術書の読書術」読んだら面白かったので、後から見返せるようにまとめました。 この本はどんな本？ 「探し方」「読み方」「情報発信＆共有」の3つの章でコツやテクニックが書いてある 二人の技術書の著者による共著であり、考え方や思想が異なる部分もそのまま載せている 2022年10月が初版で現時点（2022年末）では比較的新しい本 各章のページ配分は以下のような感じで、表題通り「読み方」が多く書かれている ５：読み方 ３：探し方 ２：情報発信＆共有 この感想を書いた人は？ 0歳2歳を絶賛子育て中のWEBエンジニア５年目くらいの人 育休中に生活や仕事の効率を上げたいと思ってこの本を手に取った 本は読むけど、何度も見返したりアウトプットすることはあまりなかった 個人的おすすめ度：★★★★☆（4/5） GOOD：技術書大好きな著者の具体的なノウハウに触れられて刺激を受けた
Rails 7.0 + Ruby 3.1でゼロからアプリを作ってみたときにハマったところあれこれ - Qiita
Ruby on Rails Advent Calendar 2021の枠が空いていたので、あとから登録しました はじめに 個人的なプロジェクトになりますが、僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」を2022年前半にRails 7.0バージョンにアップデートしようと考えています。 そこでこの本の中で使っているサンプルアプリケーションをRails 7.0でゼロから作り直してみました。フロントエンド周りを中心に結構考え方が変わっている部分があったので、「ここでハマった！」とか「こういうポイントを押さえておくといいかも」という点をあれこれ書いてみます。 なお、Rails 7.0版のサンプルアプリケーションはまだ公開できる状態ではないので、公開はもうしばらくお待ちください🙏 今回作成したサンプルアプリケーションはこちらで公開してい
[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita
下記ドキュメントバージョンに関する注意点です。 バージョン番号のルールを定める：バージョン番号は、どのようにつけるかルールを定め、チーム全員が同じ理解で使用するようにする必要があります。たとえば、変更内容によって数字がどのように増えるか（major, minor, patch）、何桁で表現するかなど、具体的に決めておくことが重要です。 変更履歴を明確にする：どのような変更があったのか、それがどのバージョンで実施されたのかを明確にすることが必要です。これにより、何らかの問題が発生した場合に、どのバージョンから問題があるのか特定することができます。 ドキュメントの保存場所を一元化する：ドキュメントのバージョン管理には、ドキュメントを保存する場所を一元化することが重要です。それにより、異なるバージョンのドキュメントが、複数の場所に分散してしまい、誤ったバージョンが使用されることを防ぐことができま
![[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d7d131e38e26f54466aece3306435a4c09990de8/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCRG9jJTVEJTIwJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgzJTg2JUUzJTgzJUIzJUUzJTgzJTk3JUUzJTgzJUFDJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgzJUJCJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgxJUFFJUU2JTlCJUI4JUUzJTgxJThEJUU2JTk2JUI5JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz01MjE0ZDhhMTY1ZjE1ODIxNGE5NzU4Njc3MTNjOTBmNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzeWFudGllbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MTc4MmM0MTlmNzhiYTJjNTk0ODYwZmExZDc0OWYzNjQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Db088349e276a1ebcdb9dcf1e2d753094)
競技プログラミングの牧歌的勉強会をした話 - Qiita
目標 この勉強会では「参加者がAtCoderにおいて緑色になること」を目標に設定しました。この目標を設定した理由は、プログラミングに馴染みがなく筋トレしたい人、高レートを目指して競プロを始めたい人、何か別の目的のために競プロを利用しようと思っている人、それぞれにとって最初の良い目標となり得ると思ったからです。別の言い方をすると、参加者の個別の目標は色々あるかと思いますが、緑色を目指すことが各々の目標をうまくカバーしているのではないかと考えて、勉強会の目標に定めました。参加者の学びたいことは幅広いです。目標をシンプルにしたかったのでこのような文言になっていますが、競プロで強くなることだけを勉強会の目標にしていたわけではないことは付け加えておきます。 参加者 エンジニア仲間のslackで毎週告知をして、その週に時間があって参加したい人が出席する形をとっていました。参加を必須としてしまうとハード
たのしいOSSコードリーディング: Let’s read WEBrick🏠 - Qiita
この記事では、Ruby製HTTPサーバーフレームワークであるWEBrickのソースコードリーディングを行います。 経緯 去る2020年11月26日、地域RubyコミュニティTama.rbの公開イベントとしてTama.rb OSSコードリーディング部 WEBrick編を開催しました。 こちらは、原作者の一人である高橋征義さん @takahashim をお招きしてソースコードをわいわい読み、その様子をZoomでライブ配信するという試みでした。 当日学んだWEBrick内部の全体の処理の流れを振り返りつつ整理していきたいと思います。 長い記事ですが、どうぞお付き合いください🙏 WEBrickとは？ 引用: library webrick 汎用HTTPサーバーフレームワークです。HTTPサーバが簡単に作れます。 現在はCRuby本体に同梱のHTTPサーバーツールキットとして知られているWEBri
Re:FizzBuzzから始めるRust生活 - Qiita
新しいプログラミング言語に入門するためには、やはり手を動かすことが大事です。本を読んで体系的に学ぶのももちろん重要ですが、それは言語の魅力を知ってからでも遅くはありません。 しかし「Hello World」レベルだと簡単すぎて言語の違いを味わえず、ネットワークプログラミングのような高度なプログラミングはフレームワークの力が大きすぎて言語とフレームワークの狭間で立ち往生することになります。 そこで登場するのが「FizzBuzz」です。「FizzBuzz」は単純なプログラムでありながら、プログラムの真髄である「順次」、「分岐」、「繰り返し」があり、数値計算も学べる興味深い題材です。 その「FizzBuzz」を利用して「Rust」という言語を学んでみようのが本記事の趣旨です。「FizzBuzz」というシンプルなプログラムで「Rust」のような表現力が豊かな言語の機能をどこまで使い尽くせるのかは興
Goコンパイラをゼロから作って147日でセルフホストを達成した - Qiita
Go言語コンパイラをスクラッチから書いてセルフホストを達成しました。 本家Goコンパイラの実装はほとんど見ずに、ほぼ 8cc というCコンパイラから学んだ知識のみで作りました。 特徴 コンパイルするとアセンブリを吐きます 字句解析・構文解析は手書きです。yacc/lex などのツールは使っていません 標準ライブラリも自作です コード行数はテストをのぞくと 9,152行でした。 セルフホストに必要な機能しかないので、Go言語の全機能は網羅していません。 例えば以下の機能は未実装です。 ガベージコレクション go routineとchannel 浮動小数点 設計 70%くらいは 8cc の設計をそのまま引き継いでいます。 残り25%(map,slice,interface,method,型推論等)が自分のオリジナル、残り5%が9cc、くらいな感じです。 かかった期間 2018/10/7に着手し
COTOHA API新元号対応 - Qiita
新元号は令和 本日ついに新元号が発表されましたね。５月１日からは平成が終わり、令和になります。 ということで、私たちのCOTOHA APIで早速新元号対応をいたしました。 以下が構文解析と固有表現抽出結果です。 APIの利用方法は公式ページやこちらの記事に説明がありますので、試してみてください。 parse (構文解析）結果 入力文：「新元号は令和になりました」 {'message': '', 'result': [{'chunk_info': {'chunk_func': 2, 'chunk_head': 1, 'dep': 'D', 'head': 2, 'id': 0, 'links': []}, 'tokens': [{'attributes': {}, 'features': [], 'form': '新', 'id': 0, 'kana': 'シン', 'lemma': '新'
オレ プログラム ウゴカス オマエ ゲンシジン ナル - Qiita
ガイヨウ オレ オマエ ゲンシジンスル プログラム カイタ ゲンシジン ジョシ ツカワナイ ゲンゴショリ スル ジョシ ケス ゲンシジン カンジ ヒラガナ シラナイ ゼンブ カタカナ スル サンプル import requests import json import sys BASE_URL = "https://api.ce-cotoha.com/api/dev/" CLIENT_ID = "オマエ アイディ イレル" CLIENT_SECRET = "オマエ シークレット イレル" def auth(client_id, client_secret): token_url = "https://api.ce-cotoha.com/v1/oauth/accesstokens" headers = { "Content-Type": "application/json", "charse
執筆活動を支える技術 #ruby超入門 - Qiita
「ゼロからわかる Ruby🔰超入門」という本を書きました。共同執筆での作業を効率的に進められるように、編集者・レビュワーさんを含め、みんながいつでも最新の原稿を確認できるように環境を整えました。ここでは、技術面・環境面で工夫したこと、得た知見を共有します。書籍に限らず、技術文書の作成にも使えます。 はじめに この本は、 @igaiga さんと共同で執筆しました。イラストを描いてくれた @becolomochi さんを含めて、3人での共同作業でした。原稿を書いてから公開するまでのフローはこんな感じです。プログラミングでの開発に似ています。 原稿を書く (Asciidoc, Atom, Visual Studio Code) 共有する (GitHub, Slack) HTML/PDF形式に変換する (Rakefile, CircleCI) 限定公開する (docker, nginx) Ste
Goのarrayとsliceを理解するときがきた - Qiita
対象 sliceしか使わないのでarrayのことは知らなくてもいいと思っているGopher 内容 arrayを理解するとsliceをもっと理解できる 参考 以下のページを主に参考にしたのでちゃんと知りたい場合はこっちを読んだほうがいい The Go Blog - Go Slices: usage and internals The Go Blog - Arrays, slices (and strings): The mechanics of 'append' きっかけ サイズを指定して宣言したsliceが引数の型チェックに引っかかり悩む、というおそらくは初歩的なつまづきをしてしまった。 func main() { s := [3]int{} takeSlice(s) // Error: cannot use s(type [3]int) as type []int in argument
ITエンジニアはかっこいい - Qiita
はじめに 皆さんはエンジニアと呼ばれる人達を どのような人達だと思っていますか。 エンジニアになった今だからこそ 実はこんなにかっこいいんだよ！ っていうのをお伝えします。╰( ^o^)╮-｡･*･: ※あくまで個人的な意見です。 私が実際にエンジニアになるまでに抱いていた印象 ・コミュ障 ・メガネかけた男性ばかり ・別世界すぎて会話も合わなさそう こんな感じでした。(すみません。。) 私は手に職が欲しかった為 こんな印象ではいたけれど エンジニアとして働くことにしました。 そして！ 実際に働いてみて気づきました、、 全然印象と違う！ まずシステムを作る時には 必ず使う人のことを考えます。 「喜んでくれるかなー？」 「便利！って思ってくれるかなー？」 相手を思い適当な考え方をしていない。 また、質問されたことに対して どうわかりやすく伝えれるかを考えます。 「ここのサイトが参考になるよ！
ソートアルゴリズムを極める！ 〜 なぜソートを学ぶのか 〜 - Qiita
NTT データ数理システムでリサーチャーをしている大槻 (通称、けんちょん) です。 今回はソートについて記します。 0. はじめに データ構造とアルゴリズムを学ぶと一番最初に「線形探索」や「ソート」が出て来ます。これらのテーマは応用情報技術者試験などでも頻出のテーマであり、アルゴリズムの Hello World とも呼ぶべきものです。 特にソートは、 計算量の改善 ($O(n^2)$ から $O(n\log{n})$ へ) 分割統治法 ヒープ、バケットなどのデータ構造 乱択アルゴリズムの思想 といった様々なアルゴリズム技法を学ぶことができるため、大学の授業でも、アルゴリズム関連の入門書籍でも、何種類ものソートアルゴリズムが詳細に解説される傾向にあります。本記事でも、様々なソートアルゴリズムを一通り解説してみました。 しかしながら様々な種類のソートを勉強するのもよいが、「ソートの使い方」や
新人プログラマに知ってもらいたいRabbitMQ初心者の入門の入門 - Qiita
題名はここオマージュです。 背景と目的 勤めている会社では、メッセージングのミドルウェアとしてAMQPというプロトコルを利用しているRabbitMQを使用しています。 RabbitMQについては、公式サイトの説明が充実しているので、業務で使用を考えている方は 基本的にこちらを読むことをお勧めいたします。 ただ、自分で調べていて 公式サイトの内容は英語 日本語のサイトを調べようとしても情報が少なかったり散らばっている そもそもメッセージングのミドルウェアがどういったもので、どういう際に必要になるかの説明が少ない ことで結構段取り時間がかかってしまいました。 そこで、RabbitMQに関わることとなった時の自分を想定しながら、 対象: 急にRabbitMQに関わるようになった人 効果: 公式サイトや英語サイト見て実装する前段階の(本当に簡単な)見取り図 所要時間: 10分 となればと思い、まと
Emacs で時の流れを感じる - Qiita
なにをやったの ふらっと外に出てみたらちょうど空が夕焼けていて「ずいぶん日が短くなってきたなあ」とか、あるいは夜、なんとなく空を見上げてみたら綺麗な満月で「もうひと月たったか」とか、そんな、ふと時の流れを感じる瞬間が僕は好きです。 が、社会人になってから、退社したら外はもう夜、という日がほとんどになって、そんな瞬間を感じることが減ってしまったなあとふと思いました。 そんなわけで、その時刻の空の色（イメージ）、月齢、天気を反映した時計ウィジェットを作ってみました。モードラインなどに置いておくと、ふと目をやったときに、ちょっとほっこりできるかもしれません。 スクリーンショット モードラインに設置 色のサンプル インストール GitHub: https://github.com/zk-phi/sky-color-clock load-path の通ったディレクトリにダウンロード (clone)、
業務でWebサービス開発をする際に気をつけたいこと（新卒向け） - Qiita
趣味でも業務でも日々Webサービスを開発しているzaruです。こんにちは。ついにアドベントカレンダーも最終日です。まだサンタとしての仕事が残っています。さて今回は仕事としてWebサービスを開発するときに気をつけたいポイントを紹介します。まぁ仕事に限った話じゃないですが…参考になれば幸いです。特に新卒プログラマあたりに読んでもらえればと思います😀 なお僕の業務上インフラ周りはAWSが多いです。 RASISという指標 RASISという指標があります。コンピュータシステムの評価指標5つの頭文字を取ったものです。 Reliability（信頼性） Availability（可用性） Serviceability（保守性） Integrity（保全性） Security（機密性） 今回はこの5つの指標に沿ってポイントを紹介していきます。RASIS自体については色々なところで解説されていると思うので
ngx_mrubyでSlackのスラッシュコマンドをつくる - Qiita
slackの設定をします。今回はGETですね。 /helloを実行、と。 Only visible to youとあるように、このメッセージは自分しか確認できませんが、とりあえず反応してもらえました。結果が他に見えない場合、入力したコマンドもチャンネルには表示されません。 見た目などはSlackの設定で好きなように変更しましょう。今回はカレンダーのネタ出しを私に振ってきた@matsumotoryを使います。 JSONでレスポンス 惜しいことにプレーンテキストでは、コマンドを実行したユーザでしか実行結果が見えません。 このあたりの挙動を変更するのも簡単で、レスポンスをapplication/jsonにしてresponse_typeパラメータをin_channel(デフォルトの挙動はephemeral)にするなどでOKです。 ついでにスラッシュコマンドの引数によって、すこし挙動を変えたりしてみ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「まずは当たり前のことをやってから言え」 - Qiita
