考えてみた

増田でこんな記事を見つけた。

IT客先常駐のイメージは私が新卒でSES会社から派兵されてた10年前から変わらないんだなーという感想とともに、いや今はそんな酷くなくないか？って感想も沸いてきた。

ダリ先生に書いてもらいました

ジェネレーティブAIが盛り上がってますね。
新卒未経験から早10年IT業界にいますが、これまでにない変化が起きてるなと、毎日出てくるニュースに戦々恐々しています。
私は今はマネジメ

DynamoDBのテーブル設計をドキュメントに起こすにあたって、属性と型を並べたような一覧表はよく見かけるが、RDBのテーブル設計で必ずと言っていいほど用意するER図のようなドキュメント例がどこにも見当たらなかった。

以前書いた記事の焼き直しになります。

あれから何度かDynamoDBを使ってきて、考えなおすところもあったので。

用途によっては無理に１つのテーブルにまとめなくてもいいんじ

SPA開発に進めていくにあたって、先にフロントエンドの開発が先行していることが多く、バックエンドはAPI設計のSwaggerこそあるものの実装されたものがなく、フロントエンドとバックエンドの結合に大きなコストがかかるってのを

先日こんなツイートをみかけました。

まだ、SESやSIer会社で勤務していた頃、散々現場で見かけたのを思い出して懐かしい気持ちになりました。

不思議なことにどこに行っても多少の差は

いよいよ10月から軽減税率が施行されますね。

増税で家計が圧迫されるのは頭の痛い問題ですが、システム屋としては複雑怪奇なルールに対応するためのシステム設計・改修に、より頭を抱えることだと思います。

バッチファイルはWindowsでの処理を自動化するために昔から手軽でよく使われる手段です。

ただ、コマンド構文が貧弱なのとそもそもプログラミング言語ではないため、複雑な処理や大規模な処理を実行するのには向いていま

DynamoDBを使いだして、DynamoDBの仕様やNoSQLへの理解不足ゆえに、あーこれ設計ミスったなーとか、設計段階で考慮すべきだった問題が噴出してきたので、知見をまとめてみます。

テーブル設計より先に

トラックナンバーという言葉があります。

プロジェクトのメンバーの内、トラックに轢かれるとプロジェクトが継続困難になる人数。人数が少ないほどリスクが高まる。
情報共有や共同開発を活発に行うと増加す