タグ

システムに関するatm_09_tdのブックマーク (143)

  • Linux/Macのクールなシステムモニタコマンド「gtop」 | マイナビニュース

    nixCraftは2017年11月6日(米国時間)、「gtop: Awesome system monitoring dashboard for Linux/macOS Unix terminal|nixCraft」において、LinuxmacOSのターミナルで利用できるシステムモニタリングコマンド「gtop」を紹介した。プロセッサ、メモリ、スワップ、ディスク、ネットワーク、プロセスなどの情報をモニタリングできる。 インストール方法は次のとおり。 macOSでのインストール方法【Homebrew】 brew install node npm install gtop -g Ubuntuでのインストール方法 sudo apt install npm sudo npm install gtop -g sudo ln -s /usr/bin/nodejs /usr/bin/node gtopを実

    Linux/Macのクールなシステムモニタコマンド「gtop」 | マイナビニュース
  • 分散システムについて語らせてくれ。顛末と反省。 - Software Transactional Memo

    8/10のNTT Tech Conference #2 にて発表の時間をもらってこのタイトルで喋ってきた ntt-developers.github.io 発表が決まるまで これはNTTグループ内のソフトウェア・ネットワーク系技術者が集まるコミュニティで、誰が発表者になれるかは投稿されたProposalに対するコミュニティ内での投票によって選考される。 何を話したいか自分の中でも固まりきっていなかった上に、主催者の話をロクに聞いていなかった自分は小さい部屋で僕のことを知る人しか集まらない不人気セッションを勝手に想像しており、abstractを書く欄に「実世界で使われている分散システムを構成する際に理解してほしい議論についてkumagiが一人で滔々と語る。」という漠然とした説明を書いた。初心者にこそ聴いて欲しいという身勝手な理由でレベル設定をBeginnerにし、自己紹介欄に至っては当は経

    分散システムについて語らせてくれ。顛末と反省。 - Software Transactional Memo
  • 効率的に仕事するために考えて欲しい7つのこと - ゆとりずむ

    こんにちは、らくからちゃです。 システム業界に身を置いておりますと、色んなお客様とお仕事をさせて貰う機会があります。システム構築はお客様との二人三脚。お客様の作業効率が弊社の作業効率に直結することも多いものの、横から『こうしたほうがええんとちゃうの?』とも言い出せず、悶々としてしまうときがあります。 そこで直接は言いづらい『ここらへん考えてみてほしいなー』という点について、だらだら適当に書いてみます。ありきたりのことしか書きませんが、どこかのプロジェクトの燃焼速度が多少なりとも遅くなれば幸いです。 例題 例えば、上司からこんな風に指示されたものとします マーケの部長が、修理案内の通知を封筒に詰めて送る作業をやってくれるひと探してるんだけど、お願いしてもいい? 宛先と対象商品と諸々が書かれたA4用紙が1000人分くらい来るからさ、宛先が東日なら茶色、西日なら白色の窓付き封筒に入れて糊付け

    効率的に仕事するために考えて欲しい7つのこと - ゆとりずむ
  • repost - みんなで投稿する日報システム MOONGIFT

    MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました 日報が日独自のシステムなのか分かりませんが、日々の作業記録をつけるのは大事なことです。記録しておかないと後で振り返ることもできず、自分の成長を知ることさえできなくなります。蓄積は日々行わなければなりません。 そこで使ってみたいのがrepostです。repostは日報システムになります。 repostの使い方 repostのメイン画面です。 中央のペインをクリックすると日報の詳細が読めます。 新しい日報を書きます。Markdownが使えるようです。 プロフィールです。 repostでは恐らく相手を指定したりできるようなのですが(@があるので)、まだ実装されていないのかうまく動きませんでした。日報を通じて仕事で困っている点を共有したり、サポートするのはよくあることです。皆が同じ場所に

    repost - みんなで投稿する日報システム MOONGIFT
  • システムズ・エンジニアリングとは何か | タイム・コンサルタントの日誌から

    にはあまり知られていないが、欧米では確立され重視されている技術の分野がある。それは「システムズ・エンジニアリング」=システム工学である。 ・・と書けば、“何を馬鹿な”と思われる方が大半であろう。日にはシステム・エンジニア(SE)と呼ばれる職種の技術者が、少なく見積もっても十万人単位で存在する。それに、大学でもそれなりに教えているではないか。「システム工学」と名のつく学科だって、数十は存在する。それなのに、「あまり知られていない」などとは何ごとか! そう憤慨される読者諸賢に、それでは、一つご質問したい。貴方が学校で学ばれた「システム工学」の、代表的な教科書をあげていただきたい。これ一つ読めば、システム工学の基礎が大体分かる、読んでいない奴はモグリだ、というような定番の教科書である。システムとは何を指すのか、システムはどのように設計すべきか、設計手法は何があるのか、システムの分析や評価は

    システムズ・エンジニアリングとは何か | タイム・コンサルタントの日誌から
  • 書評: 進化する銀行システム 24時間365日動かすメインフレームの設計思想 - Qiita

    発端 去年、Naoya Ito さんがこんな話(System of Record と System of Engagement)をした後、SOEとかSORとか話題になることも多くなったと思う。 そんな折、ちょうどいいタイミングで、SOR中のSORなシステムである銀行システムの話を、日における銀行システムの曙までさかのぼってまとめたが出たのでさっそくゲットした。 Title: 進化する銀行システム 24時間365日動かすメインフレームの設計思想 (Software Design plus) Publisher: 技術評論社 (Feb. 2, 2017) Author: 星野 武史 (著), 花井 志生 (監修) ISBN-13: 978-4774187297 Publish Date: 2017/2/4 Amazon: https://www.amazon.co.jp/dp/477418

    書評: 進化する銀行システム 24時間365日動かすメインフレームの設計思想 - Qiita
  • 工場レイアウト設計の典型的問題と、そのエレガントな解決法 | タイム・コンサルタントの日誌から

    工場見学ほど面白いものはない。なぜなら、工場はそれ自体が大きくて複雑なシステムそのものであり、そのシステム作りに各社独自の工夫も盲点も現れてくるからだ。——そういう意味のことを、これまで何度も書いてきた。また、すでにお知らせしたとおり、来る7月20日(水)に「生産革新フォーラム」(通称「MIF研」)で『上手な工場見学の見方・歩き方 〜エンジニアリング会社の視点から〜』というタイトルでお話ししたいのも、その点だ。だが、もう少し具体的に、わたしがよその工場を訪問したら、最初にどこを見るかについて書いてみたい。 ものづくりの方式やプロセスにはいろいろバリエーションがあるが、機械組立加工系を例にとると、だいたい次のような工順(工程順序)をふんでいる: 材料受入 → 部品加工 → 組立 → 検査 → 梱包出荷 この途中に通常、「在庫保管」も入るが、どこに入るかは工場の方針次第のため、ここでは省略して

    工場レイアウト設計の典型的問題と、そのエレガントな解決法 | タイム・コンサルタントの日誌から
  • ユーザ側の『ITイノベーター』こそ、急いで育成するべきだ | タイム・コンサルタントの日誌から

    昨年のことだが、あるITコンサル兼調査会社の主催するカンファレンスに出席した。参加者は大手企業や官庁などのITリーダーばかり40〜50人ほど。「ITリーダー」というのはやや微妙な表現だ。主催者側は当は「CIO」の参加を期待したのだろうが、実際の参加者の大多数は、情報システム部長さん達だったので、こういう言葉を使ったらしい。わたしはCIOでも情報システム部長でもないが、まあ現在は社内の中期的な情報戦略をつかさどる立場なので、この場に混ぜていただいた。 わたしが参加したセッションは二つ。「グローバル企業のITガバナンス」と、「IT人材の育成」をテーマにしたものだった。円卓を10数名で囲んでディスカッションする形式で、コンサルタントが議論をファシリテートする。なかなか興味深い試みだったと思う。同席したのは、自動車会社が3社、大手通信業者、大手製造業、外資系メーカー、エネルギー企業、航空会社な

    ユーザ側の『ITイノベーター』こそ、急いで育成するべきだ | タイム・コンサルタントの日誌から
  • Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ

    主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /

    Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ
  • 2038年問題 - ablog

    glibc で time_t は long int で、gcc で 32bit モードでコンパイルすると 32bit、64bit モードだと 64bit になる(ワードサイズになる)ということぽい。 LONG_TYPE_SIZE A C expression for the size in bits of the type long on the target machine. If you don't define this, the default is one word. GNU Compiler Collection (GCC) Internals 参考 Linuxシステムプログラミング 作者: Robert Love,ロバートラブ,千住治郎出版社/メーカー: オライリージャパン発売日: 2008/04/16メディア: 大型購入: 5人 クリック: 181回この商品を含むブログ

    2038年問題 - ablog
  • 追加見積もりに合意していない作業に支払いの義務はあるか?

    IT開発というのは面倒なもので、一旦、要件を凍結した後でも、五月雨式にその追加・変更が発生します。五月雨式に次々と湧いてくるわけですから、一つ一つ、契約の見直しや金額の合意をしていたのでは仕事になりません。ですからユーザーもベンダーも、やることが決まっている作業であれば、正式な見積もりや契約変更は後回しにしてとにかく作業を先行させようということになります。 こういう場合、ユーザーとベンダーが作業内容や工数について、正しい理解を共有しているのであれば問題は起きません。しかし、双方の理解に齟齬があれば、両者は対立することになります。 「この機能、入れるって話だよね?」 「いえ、それは、まだ決まっていません。」 「こちらが、今回の追加作業についての、お見積りになります。」 「ええ?金払うの?」 ITの世界では、こんな会話もめずらしくありません。このように、追加要件と費用について合意のないまま作業

    追加見積もりに合意していない作業に支払いの義務はあるか?
  • Windowsのsysteminfoコマンドでシステムの情報を収集する

    PCのシステム構成をリモートから取得したい! ネットワーク上に存在するWindows PCの一覧を調べ、それらのシステム構成やOS、ネットワークなどの設定情報を把握しておくことは、システム管理の基的な作業である。 といっても、いちいち各PCの設置場所にまで出向いてシステム情報を収集するのでは非常に手間が掛かる。可能ならばリモートから情報を収集するようにしたい。 Windows OS上でシステムの情報を収集するためのコマンドには幾つかある。そのうち、Tech TIPSでは「systeminfo.exe」コマンドを紹介する。これはコマンドプロンプト上で利用するツールであり、ローカルのシステム情報だけでなく、リモートPCの情報も収集可能だ。 「systeminfo」コマンドで表示される情報には、コンピュータ名やOS、メモリ容量、ドメインコントローラやメンバーサーバといったシステム構成の情報、

    Windowsのsysteminfoコマンドでシステムの情報を収集する
  • みずほ銀行が桜田ファミリアなら、ゆうちょ銀行のシステム建造物は大仏建立になるかもしれない : 市況かぶ全力2階建

    フィル・カンパニー、社会人3年目の広報担当が決算発表日にSNSで無駄に期待を持たせて株価を乱高下させた件でお詫び

    みずほ銀行が桜田ファミリアなら、ゆうちょ銀行のシステム建造物は大仏建立になるかもしれない : 市況かぶ全力2階建
  • ゆうちょ銀行のシステム統合はみずほ銀行の次期システムどころじゃない史上空前の大プロジェクトになりそう。

    (๑╹◡╹๑) @tsuchie88 まぁ何とか上場した郵政三社なんだけど、構造的に郵便事業の赤字を金融二社の儲けで埋めるって言う状態には変わりないわけで、ある意味で持ち株会社の日郵政も、金融二社の存在がないと結構実態はどうなのか、と思ったりするのだが (๑╹◡╹๑) @tsuchie88 上場によって、形式に日郵便の金融二社への持ち株比率は下がって、今後POの実施で資的な関係は薄れていくと思うけど、収益力が今後どれだけ向上できるのかは不安視されてるが、わしが割と心配なのはガバナンスとITシステムどうするんだろうというところが結構気になってる (๑╹◡╹๑) @tsuchie88 特に、ゆうちょ銀行の情報システムはかなり問題が多く、IT関連の費用が毎年1000億円台後半くらいはかかってる。公社時代に、ITシステムの合理化がかなり進められて、経費率は下がってるんだけど、民営化と上場でま

    ゆうちょ銀行のシステム統合はみずほ銀行の次期システムどころじゃない史上空前の大プロジェクトになりそう。
  • 産業用IoTが生み出す(かもしれない)、新しい『つながる工場』のコア技術とは | タイム・コンサルタントの日誌から

    IoT(Internet of Things=モノのインターネット)という言葉は、現代のIT関連業界では最大の流行語だろう。デジタル的に接続可能なデバイスが全て、インターネットを介して通じ合う。そんな世界像から様々な技術や市場が生まれる、という期待感が世の中にあふれている。 その事情は米国でも変わらない。たまたまこの文章は米国ヒューストンのホテルで書いているが、雑誌やWebなどで見てもIoTの記事の注目度は高いようだ。先週もEmerson社(工場自動化メーカーの大手)が新しい顧客提案を発表したとか、SAP社がIoT部門を新設したとか(これはドイツ企業だが)、かまびすしい。 IoTには、スマホなど一般消費者向けデバイスをビジネスにつなげる面と、産業用途としてIoTを利用する面とがあり、後者を区別のためにIIoT(Industrial IoT)と呼んだりしている。調査会社ARCの発行するIIo

    産業用IoTが生み出す(かもしれない)、新しい『つながる工場』のコア技術とは | タイム・コンサルタントの日誌から
  • なぜ生産管理システムはちゃんと機能しないのか | タイム・コンサルタントの日誌から

    ずいぶん刺激的なタイトルではある。まるで佐藤は、生産管理システムを作って販売している大手の全ITベンダーを敵に回しているようではないか。だが、趣旨はまったく逆である。生産管理システムを使おうとしているユーザ企業(つまり製造業)の無意識に持っている前提や期待が、現今の生産管理システムのよって立つロジックとかけ離れている点を指摘しよう、というのがねらいだ。そうして、もっとユーザが不満を持たずにちゃんとITツールを使いこなせるようにできたら、と思ってこの文章を書いている。 もっとも、こう書くと今度はユーザ側から、「滅多なことは言わないでくれ。ウチはちゃんと生産管理システムを使っているぞ」と反論されるかもしれない。とくに結構な金額のソフトウェアを購入した現場ほど、そうであろう。社長に導入効果を聞かれて、いや、まだうまく動いていませんとはまさか答えられない。 経営者の側だって同じである。「はい、当社

    なぜ生産管理システムはちゃんと機能しないのか | タイム・コンサルタントの日誌から
  • 障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか?」 | POSTD

    私はポストモーテム(事後分析)の記録を読むのが大好きです。ポストモーテムを読むと勉強になりますが、大抵の教材的資料とは違って、興味深いストーリーが含まれているのです。相当な時間をかけてGoogleMicrosoftのポストモーテムを読みました。大きな障害を招く最大の原因について、私は(まだ)きちんと分析していませんが、何度も繰り返し目にするポストモーテムのパターンがいくつかあります。 エラーハンドリング 適切なエラーハンドリングのコードを書くのは難しいものです。エラーハンドリングのコードに含まれるバグは、 大きな 問題を引き起こす主な原因となっています。つまり、エラーによってバグのあるエラーハンドリングのコードが実行されるということは、単に個々のエラーが重なるだけという事態にはとどまらないのです。障害が重なって重大なシステム停止につながることはよくあります。それはある意味明らかなことで、

    障害の事後分析を読んで得た教訓 ― 「何がシステムを停止させるのか?」 | POSTD
  • 生死をも左右するソフトウェアの設計・構築はどうすれば完璧に近づけられるのか?

    By Lwp Kommunikáció 多くの装置がコンピューターによって制御されるようになった現代では、機械そのものの安全性はもちろん、それを制御するプログラムの安全性が極めて重要です。その中でも特にコンピューターによる制御が多く取り入れられている旅客機と、技術の粋を集めた宇宙ロケットの制御ソフトウェア構築の現場では非常に高い正確性が求められるのですが、そこで取り入れられている方法や思想についてまとめられています。 How Is Critical 'Life or Death' Software Tested? | Motherboard http://motherboard.vice.com/en_uk/read/how-is-critical-life-or-death-software-tested 多くの乗客を乗せて空を飛ぶ旅客機は、今ではその多くに「フライ・バイ・ワイヤ(FBW

    生死をも左右するソフトウェアの設計・構築はどうすれば完璧に近づけられるのか?
  • リリースフローを自動化して、本来の開発業務に専念できる環境を整備しよう

    人はミスをしてしまうもの 開発・運用に携わる人には釈迦に説法ではありますが、どれだけ詳細なリリース手順書を整備しても、ダブルチェックのルールを設けても、天才プログラマを何人集めてもミスや失敗は付き物です。経験則からもそうですが、特に稼働が高い時(ローンチ前後)、時間がなくて焦っている時(障害時)はミス・失敗が起こりがちです。 昨今のリリース手順は簡単に思いつくだけでも、 コンパイルの実行 ユニットテストの実行 カバレッジの取得 minify,compressの実行 依存関係の解決 など、複雑化しがちです。 手作業でリリースする場合、一つ一つの作業は微々たる時間で行えても、リリースに必要な作業を積み重ねると結構な時間がかかります。また、それを継続的に行っていくとなるとかなりの時間を取ってしまいます。 これらの作業を自動化することで、機能開発・研究開発と言うエンジニア来の業務が行える環境を整

    リリースフローを自動化して、本来の開発業務に専念できる環境を整備しよう
  • 論理クロックの原典をあたる - obfuscatism

    この記事は システム系論文紹介 Advent Calendar 2014 の25日目のエントリである。 注意点としては、私は分散システムの専門家とは言い難いので、読者自身で確信・確認できることから信じていってもらいたい(間違った知識を覚えないように。もちろん誤りのないよう努力はしている)。 はじめに Advent Calendar 最終日だけど特に締めとしてシステム系とは何ぞやと語ることはせず、分散システムにおいて有名な論文を今回も短めに紹介する。 「システム系論文」の定義っぽいものや、それと思われる論文の調べ方・読み方については23日目のy_uukiさんのインフラエンジニア向けシステム系論文 - ゆううきブログがよくまとまっているので、そちらを読むのがオススメである(ハテブ数も多い!)。 エントリで紹介するのはLamport先生の以下の論文となる。見ての通り1978年だ! そのとき私は