システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ
アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい
Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション（session）の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基本仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略
ユーザー目線って何？システムの速度を6倍にしたのに上司に怒られた話 | KonifarPod
最近『ユーザー目線』という言葉をブログ記事でよく見ます。言葉自体は太古の昔からあったわけですが、正直僕はこの言葉がよくわかりません。ユーザー目線って、なんかふわっとして意味不明じゃないですかね？ユーザー目線で考えるのは悪くないけどユーザー目線になるのはよくないというか、なんかよくわかんない微妙な言葉だと思います。 と言っても、最初からこんなことを考えていたわけではありません。なぜこんな考えになったかというと、新卒の時ユーザー目線の認識を間違えて見事に大失敗したからです。具体的に言うと、システムの速度を改善して１時間から１０分にしたら上司に怒られたんですね。今回は、ちょっと当時の失敗を思い出しながら自分の思考を整理してみようと思います。主観１００％になりますが悪しからず。 １．とりあえず全力だった新卒の僕 「この機能遅くてお客さん困ってるからいい感じにしといて」 パッケージベンダーのエンジニ
タクシー業界を変えた『日本交通タクシー配車』は、情シス社員2人の挑戦から生まれた【特集:スマホが企業を救う】 - エンジニアtype
トップページ > 旬ネタ > タクシー業界を変えた『日本交通タクシー配車』は、情シス社員2人の挑戦から生まれた【特集:スマホが企業を救う】 スマートフォンのGPS機能を使ってタクシーを呼び出すO2Oアプリが人気を博している。現在、類似アプリが複数存在しているが、その先駆けとなったのが『日本交通タクシー配車』だ。 開発を担当した日交データサービスは、1977年に日本交通グループのシステム部門として発足して以来、配車や顧客管理、給与計算、日報管理など、同グループにおける基幹業務システムの開発と運用を行っている。社名や業務内容から想像される通り、この配車アプリの開発に乗り出すまでは、自社ホームページ以外でBtoC向けサービスにかかわることはほとんどなかったという。 システムグループリーダーの若井吉則氏は当時を振り返る。 「ガラケー全盛期に携帯向けの『モバイル配車』というサービスを提供していたこと
ITアーキテクトは何をしているのか
情報システムの「アーキテクチャー」にもっと目を向けるべきではないでしょうか。部分最適の積み上げで全体として必要以上に複雑で歪なアーキテクチャーになっているケース、性能問題など保守・運用上に課題を抱えて事業の採算が合わないケース。筆者の周りでもこうしたケースを見聞きすることは少なくありません。また、ビジネス上の本質的な目的を捉え、目覚ましい進化を遂げるハードウエアを活かすのもアーキテクチャー次第だといえます。 情報システムのアーキテクチャーに責任を持つのはITアーキテクトとされています。その重要性は増していますが、人数が少ないのが実情です。どうしたらなれるのでしょうか。どのように育てたらよいのでしょうか。一つの方法は、ITアーキテクトが実施していることを真似てみることだと思います。 ITアーキテクトが何かをするのであれば、そこには「成果物」が生まれます。そして成果物には必ず目的があります。そ
大きなリリースの際にチェックすべき34のこと
以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システム・エンジニアの基礎知識