タグ

2017年2月13日のブックマーク (10件)

  • 書評: 進化する銀行システム 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
    memoyashi
    memoyashi 2017/02/13
    木構造/ネットワーク構造DBはポインタをたどってレコードを探す。うまく設計すれば親子レコードを物理レベルで近くに配置でき読取ブロック数を少なくできるのでリソースの少なかった昔は取られた手法です。
  • Migrate Sybase IQ to Amazon Redshift - Ispirer

  • Microsoft SQL Server、Sybase Adaptive ServerおよびOracleの比較

    2 Microsoft SQL Server、Sybase Adaptive ServerおよびOracleの比較 この章では、Microsoft SQL Server、Sybase Adaptive ServerデータベースとOracleデータベースとの比較について説明します。 内容は次のとおりです。 スキーマの移行 データ型 データ記憶域の概要 データ操作言語 スキーマの移行 スキーマには、表、ビュー、索引、ユーザー、制約、ストアド・プロシージャ、トリガーおよびデータベース固有のその他のオブジェクトの定義が含まれています。ほとんどのリレーショナル・データベースは、類似したオブジェクトとともに動作します。 この項では、次の項目について説明します。 スキーマ・オブジェクトの類似点 スキーマ・オブジェクト名 表の設計上の考慮事項 スキーマ・オブジェクトの類似点 Oracleのスキーマ・オブジ

  • Sybase のデータ型

    各アクティビティでの Sybase(R) のデータ型と、それに対応する LEI (IBM(R) Lotus(R) Enterprise Integrator) または DECS (IBM(R) Lotus(R) Domino 基幹連携サービス) のデータ型を次の表に示します。 (p) -- [Allow Precision Loss Only] が有効になっていないとき、型の不一致のエラーが発生します。デフォルトでは、[Allow Precision Loss Only] が有効になっています。 (o) -- データが転送されるときに、オーバーフローのチェックが行われます。オーバーフローが発生し、[Truncate Data When Necessary] が有効になっていると、エラーにはならずにデータが切り捨てられます。 この表の使用方法については、第 3 章の「Connector のデ

  • curlでJSONをPOSTする - Qiita

    curlコマンドでPOST -dでPOSTのBODYを指定。 なんとなくUserAgentiPhoneやgzip要求もつけてみる。 curl -H 'Content-Type:application/json' -H 'User-Agent:iPhone' -H 'Accept-Encoding:gzip,deflate' -d "{"key":"val","key2":",val2"}" http://~~~~~~~~~~ #!/bin/sh # Usage: xxxxxx.sh url times json # # Arguments: # url # times # json it MUST be surrounded single-quartations # # Example # sh xxxxxx.sh http://localhost:8080/webapi/user/XX

    curlでJSONをPOSTする - Qiita
    memoyashi
    memoyashi 2017/02/13
  • TechCrunch | Startup and Technology News

    While funding for Italian startups has been growing, the country still ranks eighth in Europe by VC investment, according to Dealroom. Newly created Italian Founders Fund (IFF) hopes to help…

    TechCrunch | Startup and Technology News
  • 記事を書く速度が3倍に!「新しい文章力の教室」が素晴らしかった

    正式名称は「新しい文章力の教室 苦手を得意に変えるナタリー式トレーニング」。大手ネットニュースサイト、ナタリーで新人教育を担当している筆者が、その新人教育で教えている内容をまとめたものだそうです。 ネット時代の文章力の教科書 「新しい文章力の教室」の素晴らしいところはネット時代の文章力の教科書だということです。このではまず良い文章の定義とは何か?から始まります。そして「良い文章とは完読される文章である」と定義しています。 「良い文章とは完読される文章である」というのは情報があふれ、いろんな記事が読み流され、読者が気になった文章だけしか読まれないというネット時代にマッチした考え方ですね。これはまさにネットメディアを主戦場にしてきたからできた考え方なのではないかと思います。ブロガーが学ぶとしても最適ですよね。 誰でも書ける方法論を教えてくれる 「新しい文章力の教室」で解説される文章の書き方

    記事を書く速度が3倍に!「新しい文章力の教室」が素晴らしかった
  • もはや若手は育成できない

    連載の最後として、若手ITエンジニアが抱える課題と身に付けるべきスキルの方向性を取り上げよう。 筆者はすでに40代だが、コミュニティー活動やアジャイルコーチ業務を通じて20代から30代前半の人たちと話す機会が多い。新人研修を担当し、大学を出たばかりの国内外のITエンジニアとも話す機会がある。若手ITエンジニアを観察すると、その置かれた環境の違いが見えてくる。 まずは大学までに学んできたことの変化だ。90年代後半からPCの低価格やインターネットの普及により、家庭や学校でコンピュータに容易に触れられる時代が到来した。そのころ小学生から高校生だった人たちが現在の若手ITエンジニアの世代になる。 この世代は、それぞれ異なるコンピュータ体験を持っているが、検索エンジンを使って何かを調べたり、ソーシャルネットワーキングを使ったりすることに関しては共通の体験を持っている(図1)。 プログラミングも大学で

    もはや若手は育成できない
    memoyashi
    memoyashi 2017/02/13
    "ビジネス環境の変化が激しい今、まとまった育成カリキュラムを作っている間に、世の中が変化してしまう。そこで、実際の業務経験を通じて、実践的な知識経験を持った人材を育成する。"
  • 技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記

    ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ? 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから? o 信用できないテストデータ も負債 o 現

    技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
  • SIerの下請け開発者ってレベル低すぎない? - UXエンジニアになりたい人のブログ

    ネット上ではSIer批判=技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態

    SIerの下請け開発者ってレベル低すぎない? - UXエンジニアになりたい人のブログ