日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。 https://anond.hatelabo.jp/20190205192741 COBOLは本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyやPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルなデータ処理を想定している感じ。 SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通はJavaやRubyで全体の流れを記述してデータベース入出力をSQLで書く。
こんなツイートをしてみました。 プログラミングスクールに行って、実際エンジニアにまで転職成功した人ってどれくらいいるんだろう。いいプログラミングスクールが可視化されるようにしたいので、ぜひインタビューさせてほしいんだけどフォロワーさんの中でいらっしゃったらDMいただけると嬉しいです。 — Dai (@never_be_a_pm) January 17, 2019 プログラミングスクールに行って、実際エンジニアにまで転職成功した人ってどれくらいいるんだろう。いいプログラミングスクールが可視化されるようにしたいので、ぜひインタビューさせてほしいんだけどフォロワーさんの中でいらっしゃったらDMいただけると嬉しいです。 そこでDMいただいた方から、転職成功率98%のプログラミングスクールを卒業された後の話を聞いてみたので、インタビューをまとめてみたいと思います。なお、特定のプログラミングスクールを
class Foo a where foo :: a -> String class Bar a where bar :: a -> Int instance Foo Integer where foo = show instance Bar Int where bar = id -- 型クラス制約の「和」を取る関数を定義したい someFunc :: (Foo a OR Bar a) => a -> IO () someFunc x = let y = foo x OR ("Bar:" ++ show (bar x)) in putStrLn y main :: IO () main = do someFunc (123 :: Integer) -- Integer は Foo を満たす someFunc (456 :: Int) -- Int は Bar を満たす という風に書きたい状
(編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています(頭字語はMichael Feathereによって名付けられま
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。言語サポート(Node.js)チームの伊藤(@koh110)です。 Node.js v10 も10月にLTSとなり async/await によるフロー制御は当たり前のように利用されるようになってきました。JavaScriptの非同期処理は async/await から覚える人も今後増えていくでしょう。今回はそんな非同期処理について、社内での事例を交えて記事を書いていこうと思います。 index Promise 化がなぜ重要なのか ユーザーに promisify をさせる落とし穴 Road to Promise まとめ Promise 化がなぜ重要なのか ちょうど3年前のアドベントカレンダーで、今後はいろいろなモジュー
blog.3qe.us これを読んだ感想文を書く。 結論、大量生産は無理やろとは思う。 少なくとも、「プロ」としてお金をもらって高品質なソフトウェアを0から書けるようになるにはセンスが必要だ。 そもそもそのレベルには私もなっていない。 ただ今あるモノになんとなく機能を追加するレベルに引き上げる術はもっとあると思う。 経験則でなんとなくその例をあげる。 ペアプロ OJTに近いとも言えるし、一番わかりやすい。 ここでペアプロはハローワールドまでの環境構築や実装までを各要素を説明しながらやることを指す。 まずはメンター側が目の前で順番にやってみる。 で次にメンティに同じことをさせる。 そうすると絶対詰まる。 Error: variable 'a' is undefined, line 24 こういうエラーが出るとまず英語を目の前で読む。 で理由を順番に説明して24行目を一緒に読む。 根気よく教え
新年から夢のない話で申し訳ないのだが、表題のとおりのテーマである。 note.mu という記事があって、むやみに長いので飛ばし飛ばし読んだ。 大意としては、世の中には「書けない」プログラマというのがいて(元エントリでは学生さんのようである。さもありなん)そういう人はどうやったって書けるようにならないんだから、諦めろ、という話のようである。 で、じっと手を見て、下請け底辺のIT企業にいる私たちは、このような人々をどうしてきたろうか、と考えると、「放ったらかし」にしたなあ、と思うのである。 最初のほうは優しく教えていたと思う。話したりハンズオンしている時に、あっこの子、変数のことわかってないな、と感じたら、ホワイトボードを持ち出してきて、例の"x"と書いた箱の絵に矢印を引いて、値が入っている図を書いて、「わかった?」「あ、はい」みたいなやり取りをして終わり、という程度の「教育」である。 だが、
Ubiregi Advent Calendar 2018 の 18 日目です。 ユビレジではたくさんのお客様の大量の POS データをお預かりしており、様々なバッチ処理も実行されています。今回は特定のケースでバッチ処理の一部が 30 分以上かかっていた処理を 14 秒で終わるようにした話について書きたいと思います。前回の Ruby 2.5 の SEGV と闘った話 - @watson1978 の日記 に引き続き DTrace を使った話になります。 はじめに ユビレジでは CSV ファイルでお客様が特定のデータをダウンロードしたりアップロードできる機能があります。CSV ファイルにエクスポートしたり、CSV ファイルから DB に取り込む処理を Worker を起動してバッチ処理しています。 大量のデータを保有しているアカウントと同量のデータを用意して手元の環境で試したところ時間がかかるこ
ソフトウェア品質シンポジウム2014での経験発表のスライドです。 http://www.juse.jp/sqip/symposium/detail/day1/#session_A1-3 10/09追記:ブログ記事書きました http://kokotatata.hatenablog.com/entry/2014/10/08/111353 (色の表示がslideshare上で少し変になってますので、ダウンロードした方がよいかもしれません。) JaSSTではシステムテストを自動化するとバグ修正日数が改善するというメリットについてお話ししました。 http://www.slideshare.net/kotaroogino/jasst14-tokyo SQiPではメトリクスを分析する事で、テストの自動化にはどういった課題があるか問題提起を行ったり、我々が行っている改善の施策を客観的にお話ししました。
Structured concurrency – Roman Elizarov – Mediumでは、Kotlin coroutine 0.26.0でCoroutineScopeを導入した経緯などが書かれているんですが、タイトルのStructured concurrencyってのが結局なんなのか本文中にはあんまり出てこないんですよね。 んで、CoroutineScopeの動作の理解に精一杯で、coroutineScope関数がなんなのか、どういう時に使うべきなのかよくわからないし、ましてやsupervisorScope関数なんて言われた日には意味が不明なわけです。 とりあえずlaunch関数内でasync関数呼び出したら駄目なんだな〜ふ〜んなんで? Notes on structured concurrency, or: Go statement considered harmfulを頑張
先日投稿した以下のエントリで、「使い方がわからない」という意見を多く頂いた。 mugi1.hateblo.jp マルチカーソル自体の操作方法は調べれば出てくるし、事例だけ紹介しとけばええやろ、と思っていたのだが、いきなり応用のサンプルを貼りすぎてわけがわからなかったらしい。申し訳ない。 せっかくなので、基礎から含め、どういったキー入力で上記のような操作を実現しているのかを紹介したいと思う。 🔥実践!マルチカーソル / 入門編 なおmac環境です。Windowsやその他環境の方は気合で調べてください。 また、言い訳臭くて申し訳ないが、私は普段はSublime Text Keymap and Settings Importerを使っており、SublimeTextっぽいキーバインドに変えて編集している。 一旦無効にしたうえでVSCodeデフォルトの状態で一通り調べて書いたつもりだが、もし違って
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発 Spring Fest 2018
今日はプログラミングの生産性に対して気づきがあったのでシェアしてみたい。 なぜ米国の人は生産性が高いのだろう プログラミングの生産性に関しては以前から興味がありいくつかのポストで考えたことをシェアしてきた。私は職業柄、いろんな国でいろんな人々とプログラミングを一緒にする機会が多い。その時に頻繁に感じるのは、平均的に言うと、アメリカの人プログラマが生産性が高い確率が高くて、しかもコードもきれいだという傾向にある。アメリカでお客さんと一緒にコードを書くと、お客さん自体が物凄く良く知っているし、実行力もある。アメリカの次と言うことでいうと、英語がネイティブの国もそれに近く、フランスなどの言語が近いところが続く感じなので、英語が物凄く影響すると思っていたし、実際すると思う。そのあたりの話はこちらのポストに書いてみた。 simplearchitect.hatenablog.com 定義での理解と、例
まずこれ quipper.hatenablog.com これを見たわたし pic.twitter.com/X47cK5qxTE— サンリズム・オーケストラ (@ueshita___) 2018年9月10日 「受託にいたこともあってWPでCMS作るような渋い話→WPやってたみたいな渋い人に来られても困る」、Quipperには転職することができないことがわかった— サンリズム・オーケストラ (@ueshita___) 2018年9月10日 これ出して平気なの、ブランディングというかんじがする Quipperすごい pic.twitter.com/6jvcqLFIxy— サンリズム・オーケストラ (@ueshita___) 2018年9月10日 WPまじで今すぐ捨てないとquipperに転職できないぞ!みんな捨てろ!破壊しろ!— サンリズム・オーケストラ (@ueshita___) 2018年9
つい3年ほど前まで、ネット上で伝説の投稿「本物のプログラマはPascalを使わない」を読むことが出来たのだが、今はマニアックに日本語訳を探さないと読めなくなってしまった(原文は今でもネット上で参照可能)。 私の記憶が確かならば、日本語訳が月刊『bit』というコンピュータ雑誌に85年頃?に発表されたと思う。当時の私はまだ少年で、プログラミングの師匠(ソフトハウスの正社員)から「読んでみろ」と読ませてもらった記憶があるが、当然半分も理解出来なかった。 そんな私もSEとしては老人と言われるような中年になり、昔を知らない若いエンジニアや若いエンジニア志望の人が非常に多くなった。温故知新と言うが、当時を知る人や、若い人にも読んでもらえれば幸いだ。 はじめにMarch 24, 1983 Real Programmers Don’t Use PASCAL 本物のプログラマはPASCALを使わない Ed
UNIX 開発者の一人である Ken Thompson が初期の UNIX にバックドアを仕掛けていたと言われている通称 Thompson hack を自作Cコンパイラで再現してみました。 Thompson hack は UNIX のログイン処理のコンパイル時にバックドアを仕掛けるようなコンパイラを作り、さらにコンパイラのソースコードからその痕跡を消し去るという神業です。 元ネタは Reflections on Trusting Trust という1983年に Ken Thompson が Dennis Ritchie と共にチューリング賞を受賞した際の記念公演です。 Ken Tohmpson はこの細工をしたコンパイラを配布したことはないと主張しているそうですが、このバックドアを利用したと見られる不審なログインがあったという報告もあったとのことで、実際にはベル研究所の外部に配布されていた
Go言語 FAQより引用すると 例外(exception)がない理由は? 我々は、処理構造を制御するためのtry-catch-finally形式の例外処理機構によって、コードが入り組んでしまうと考えています。 とのことです。 うーん、これだけじゃよく分かりません。 知りたいのは、 「例外機構が有用な場面」についてGo言語ではどのように対処するのか? はたしてGo言語の他の機能を組み合わせることでカバーできるのか? 「例外機構ではコードが入り組んでしまう」というのはどういうことを指しているのか? 自分の探し方が悪かったら申し訳ないですが、 講演やら Effective Go やらでこういったことに言及している部分を見つけられなかったので、 調べた内容と自分の推測をまとめてみます。 結論としては 例外機構が欲しい場面は Go 言語の他の機能でカバーできそう 例外機構によるエラー返却では、関数の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く