ITはもう面白くなくなってますね。 技術が面白いときには、いろいろ新しいものが出て性能あがったりできることが増えたりします。調べたらどんどん新しいものが出てくるし、新しいものもたくさん作るし、面白い。ですが、IT技術は一通り出そろって、成熟期に入っています。そうすると新しい技術に出会うことも新しいものを作ることも減っていきます。その結果、いままでの変化のあった状況を知っていれば、つまらんってなりますね。 ※2024/8/24 追記 言いたいことをまとめると、IT素振りのネタ探しに苦労するようになったよねってことです。 結局のところITというのは新しいハードをどう動かして社会に実装していくかというものなので、新しいハードが出ないとどうしようもないのです。けれどもだいたい飽和してしまった。 雑にいえば、これまで1980年くらいにBASIC搭載8bitパソコンが普及するとBASICプログラミング
「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。 2024/8/18追記：文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。 「詳細設計書」とはなんなのか nowokay.hatenablog.com こちらの記事では詳細設計書とは以下のようなものであると整理されている。 表現を変えたコーディング（の一種） 机上プロトタイプ（の一種） 分析資料 保守（のための）資料 （水平作業の場合の）作業指示書 （委託している場合の）契約資料 上記以外で考えられるのは次のようなものがあるだろう 利害関係者が要求している たとえば受託開発において発注者が要求している場合 ほかには連携している相手先システム側から
いわゆる「ソフトウェア設計書」が設計ではなく、ソースコードが設計であるという話。 随筆です。考えマトメ中なので、ツッコミはそのあたり踏まえていただければ。 追記：ブコメに「設計の定義は？」とあったので末尾に追加しています。 追記(2024/8/15)：設計書ってなんだろう？というのも書いておきました。 ソフトウェアの「設計書」とはなんなのか - きしだのHatena このエントリで書いたのですけど、もうすこしちゃんと。 建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？ - きしだのHatena このエントリでは次のように書いています。まあ、これで全てではあるのだけど。 「建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです」 あと「継続的デリバリーのソフトウェア工学」からの抜粋。 「継続的デリバリーのソフト
世の中には、一見関係なさそうな物理現象がITシステムに不可思議な影響を及ぼすことがあります 例えば,500マイル以上離れた場所にメールが送れないという話だったり 中国人のAさんがお茶を入れると会社のネットが繋がらなくなる という話があります。 私の場合は、祖母が就寝するとDBインサートが失敗する、という状況でした 実家の見守りシステム 問題が起きているのは、離れた実家にいる一人暮らしの祖母の状態を見守るために作成した自作のシステムです。 気温や湿度、CO2濃度、明るさ、部屋のドアの開閉、冷蔵庫の開閉の状況をモニタリングできるようにしています。 Raspberry Piに各種センサが接続され、定期的にInfluxDBに送信し、Grafanaという可視化ツールでいつでも見られるようにしています。 これらの情報を見ることで、祖母の家の部屋の温度が適切か、活動しているか、部屋にいるかなどが分かりま
はじめに 6月に凄腕エンジニアさんから学んだ例外の話というQiita記事を書かせていただいたところ、かなり反響がありました。（2023年07月08日時点で570いいね、550ストック、はてなブックマークが560usersにブックマークされています） コメントなども目を通させていただいたところ、自分に基本的な例外の知識が足りないなと思ったので、いろいろな記事に目を通したり、本を読んだりして、インプットしました。 そのアウトプットとして今回記事を書きます。 エラーと例外 この記事ではエラーと例外という二つの概念は同じ概念で交換可能なものとして扱います。 （ソフトウェア設計のトレードオフと誤りより引用） Javaでは【プログラムではどうにもできない事態が起きた時に発生するものがエラー、そうではないものは例外】というような考え方があったり、他にも【想定内であれば例外、想定外であればエラー】という考
レガシーコードとどう付き合うか 作者:めもりーシーアンドアール研究所Amazon めもりーさんの『レガシーコードとどう付き合うか』を読んだ。 これは優秀なプログラマであり、CTOとして経営に参画しためもりーさんならではの1冊でした…とはいえ、果たして人生何周目だったらその経験をここまで分かりやすく言語化できるのか分からない。 簡単に言えば、以下の記事の完全版、というか、経営とエンジニアの両サイドから見た「企業が顧客に価値を届けるという営みにおける”エンジニアリング”とは何か？」というテーマなんじゃないかと思います。 note.com [目次] CHAPTER 01 なぜレガシーコードが生まれやすいのか CHAPTER 02 レガシーコードを改善するための道筋 CHAPTER 03 レガシーコードを読む力 CHAPTER 04 レガシーコードを改善するための準備 CHAPTER 05 レガシ
概要 プログラミングの良い概念を理解するとプログラマーレベルが上がると考えています。 良い概念は特定のプログラミング言語に縛られないので、様々なプログラミング言語で役に立ちます。 前回はOAOO原則を紹介しました。 今回紹介する良い概念は「やらない理由を書いてやらない」です。 プログラミングの3大要素 本編に入る前に、プログラミングの3大要素について復習しましょう。 プログラミングを構成する3つの基本要素は「順次処理」、「分岐処理」、「反復処理」です。 プログラミングの3大要素だけであなたのやりたいことは基本的に実現できます（良いプログラミングであるとは限らない）。 1.順次処理 順次処理は記述した順番に従って処理を進めていくことです。
概要 1582年10月5日〜1582年10月14日までの10日間は、何らかの自然現象（ゴゴゴゴゴ）によって時間が消し去れてた期間として知られています。プログラミング言語を使ってこの日を取り扱おうとすると、いろんな結果が出力されます。 今日はそんな素敵な日付である1582年10月5日と戯れて、貴重な1日を無駄にしてみたいと思います。 Java とりあえずJavaから。バージョンは7。 // 1582/10/05をパース Date dt1 = new SimpleDateFormat("yyyy/MM/dd").parse("1582/10/05"); System.out.println(dt1); // 1582/10/04をパース Date dt2 = new SimpleDateFormat("yyyy/MM/dd").parse("1582/10/04"); System.out.p
はじめに この記事では、モノタロウの基幹系を構成するシステムの一つである、商品情報管理システム（PIM：Product Information Management システム）の導入プロジェクトで、商品情報を基幹系と同期するシステム（商品情報同期機能）の性能や運用環境の改善を行った話をご紹介します。 背景 モノタロウの基幹系は、長年内製のシステムで支えられてきました。基幹系のシステムは、少数のWebアプリケーションと多数のバッチから構成されています。中でも商品情報の管理に関するシステムは、在庫や仕入先に関するシステムと一体化していて、商品情報に関する数多くのマスタメンテナンス画面を備えたやや複雑なシステムです（図１）。 図1 基幹系の概略図 当社のシステムは、もともと自分たちのビジネスに必要な機能を提供する手頃なパッケージ製品がなかったため、すべてを内製でまかなってきたという経緯があります
プログラミングに必要なブレイクスルー
Yoyo Code (Matyáš Racek's blog)より。 ソフトウェアの開発方法を劇的に変えるには、いくつかのブレイクスルーが必要だと感じています。ブレイクスルーといった場合、それは大きなブレイクスルーを意味します。例えば、「構造化プログラミング」のブレイクスルーのようなもので、プログラミングに対する私たちの考え方を完全に変えてしまうようなものです。ここでは、それに関するいくつかの見解とアイデアを紹介します。 グルーコードや定型文を書くのは無駄だ 私が書くコードのほとんどは、面白いことはするわけではなく、定型文か、サブシステム同士を繋ぐための糊のようなものです。この種のコードは、すでに何度も書かれていて、これからも何度も書かれるような気がします。それなのに、なぜまた書かなければならないのでしょうか? 問題は、コードがかなり異なっていることで、通常は既存のコードをそのまま使うこと
この世には「関数電卓」と聞いて目が輝く人と、そうでない人がいるでしょう。エンジニアである私も含め、目が輝く人は、日本では少数派なのではないかと思います。残念なことです。 「電卓」がなくなって困る人は大勢いるはずですが、「関数」を知らなくても、普通に生きて行けるのも事実。でも関数がなかったら、株価を予測してお金儲けできないし、現代社会を支えるテクノロジーは明治か中世くらいに戻ってしまいます。関数は、社会科学を含む科学的現象を数学的に見るための「目」としてとても重要です。理系の学生は、「科学の目」を養うために関数電卓を使います。 「プログラミング」と聞いて目が輝く人は、関数電卓の場合よりちょっと多いかも知れません。なんと最近の関数電卓は、Pythonでプログラミングできるのです。「えっ、そうなの？」と思った人。私も同じ事を思いました。CASIOの関数電卓『fx-CG50』は、2018年に公開さ
この投稿ではJavaScriptで文字数をできるだけ正確にカウントする方法について取り上げます。 文字数とは？ 要件で「文字数を表示してほしい」「○文字以上はバリデーションエラーにしたい」と文字数を考慮しないとならないことがあります。 そもそも文字数とは何でしょうか。 たとえば、アルファベットの「A」は1文字と数えられそうです。 次の絵文字は、何文字になるでしょうか？ この絵文字はiOSであれば14.5の環境では、UI上では上のように1文字のように表示されます。しかし、それ以前のバージョンでは、同じ文字列データでも😵💫のように2文字で表示されます。なお、この絵文字は3つのコードポイントU+1F635 U+200D U+1F4ABからなります。この絵文字の「文字数」はいったい何文字として扱ったらよいのでしょうか。 以上のように、ひとことで文字数と言ってもデータと見た目と環境の3つのややこ
そもそも既存はどんなロジック？ RDBなんだからWhere句使ったら？ なぜファイルにすると速くなるのか？ 並列化と分散処理による高速化の可能性 COBOL使う必要あったの？ Javaとかじゃダメだったの？ まとめ TLを見てると以下の記事が少し話題になってました。 tech.nikkeibp.co.jp tech.nikkeibp.co.jp 対象の記事は有料会員じゃないと見れないのだけど事例としては以下みたい。 リソース - ユーザー事例 - COBOL製品 ユーザー事例 : マイクロフォーカス さて、この記事の驚きポイントは「１億レコードくらいのDB処理をRDBからCOBOL + CSVに変更してUnixサーバからWindowsサーバに変える事で性能を維持しつつコストを1/5くらいにした」という事でしょう。 「せっかく7割もあったSQLを全部COBOLに変えるとか時代に逆行しすぎ！」
東進ハイスクール・東進衛星予備校（以下、東進）を運営する株式会社ナガセ（本社：東京都武蔵野市 代表取締役社長 永瀬昭幸）は、2021年10月・11月に実施した「全国統一高校生テスト」「全国統一中学生テスト」の受験に対して独自アンケートを行った。 その中から今回は、高校生・中学生のプログラミング学習への取り組みに関する調査結果を発表した。 調査結果概要 結果詳細 8割以上の高校生・中学生が「プログラミングは必要なスキル」と認識 上のグラフは、「プログラミングが今後必要なスキルになると思うか」というアンケート結果である。 「とても思う」と「そう思う」の合計は、高校生が86.0％、中学生が83.7％だった。 学年が上がるにつれて増加する傾向にあり、高校生では全学年が85％を超えている。 多くの高校生がプログラミングは今後、重要となると考えていることがわかる。 中学1年生の半数以上が「プログラミン
前提 前提ですが。 transaction=Consistency/Isolationを担保する仕組みの話とする。 一般にtransactionが持つべき属性はACIDと言われる。C/Iに比べて、A/Dが“わかりやすい”のでAtomic/Durableの属性の方が人口に膾炙しているが、現在のtransactionではA/Dネタはあまり話題にならない。A/Dネタはローカルだけで見るのであれば普通にfile system /storageの話になる。元来Atomic/Durableはtransactionのコンテクストでは専らlogging / recoveryの話だった。そして、これは非同期のepoch-basedになるとそれ自体の取り扱い優先度が下がる。現代的なtransactionでは、「現時点ではread committedが保証されているFS/storageでA/Dの問題は(ある程度
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
物理学科で学んでいる1号から「0.1ずつたして4.0で止まるループのはずなのに、4.1までやっちゃうんだけどどうして？」という相談を受けた。 Cで書くとこんな感じ。実際はいろいろ計算が入っているが、問題はそこじゃないので削ってある。 float x=0; float step=0.1; while(x<4.0) { x += step; printf("x=%5.3f\n", x); } x=3.9でwhile(x<4.0)の条件をパスして、x=4.000を表示した後、x=4.0でwhile()の条件をパスできなくて終わるはずなんだが、パスしてx=4.100を表示してしまう。 floatだし、誤差の積み上げでx=4.000に見えるけど、実際はx=3.9999xxxなんでしょってのはまぁ推測できる。 実際、printf()の書式指定を%5.3fから%8.6fにすると、x=4.000はx=3.
こんばんは、id:kouki_dan です。突然ですが、現在は2021年ですね。あるいは令和3年です。今年が有効期限の免許証には平成33年と書かれているかもしれません。また、神武天皇即位の年を元年と定めた皇紀では2681年になります。 同じ年を表しているはずなのですが、暦によって何年なのかは違います。実はiOSは複数の暦に対応していて、日本で使われている和暦にも対応しています*1。令和元年5月にリリースされたiOS 12.3のリリースノートには、令和に対応したことが示されています。 暦を選択するのはiOSを使っているユーザーなので、iOSアプリでは端末によって複数の暦が存在しています。この記事では暦の取り扱いが不適切で実際に起きたバグとその原因、また、一般的にどのように日付を扱うべきかについて説明します。 突然、APIレスポンスのパースに失敗する 原因判明！ APIのレスポンスが閏日だった
「タイムゾーン呪いの書」は、もともと 2018年に Qiita に投稿した記事でしたが、大幅な改訂を 2021年におこない、同時にこちらの Zenn に引っ越すことにしました。 この改訂では Software Design 誌の 2018年 12月号に特集の一章として寄稿した内容も取り込みつつ、夏時間をめぐって各地で起きつつある変化について 2021年 6月現在の状況なども追加しました。そんな追記もしていたら記事全体が長大になってしまったため、この「知識編」と、「実装編」・「Java 編」に記事を分けました。「知識編」は、導入にあたる第一部です。 Qiita のほうは、引っ越した旨とこの引っ越し先へのリンクだけ追記して、しばらくそのまま残すつもりです。 はじめに タイムゾーンという概念のことは、ほとんどの人が聞いたことがあると思います。ソフトウェア・エンジニアでも多くの方が、時刻やタイムゾ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
