タグ

関連タグで絞り込む (54)

タグの絞り込みを解除

programmingと言語に関するvanbraamのブックマーク (120)

  • Go言語でのテストの並列化 〜t.Parallel()メソッドを理解する〜 | メルカリエンジニアリング


    この記事は、MerpayTech Openness Month 2020 の6日目の記事です。 メルペイでBackendエンジニアをしている柴田︵@yoshiki_shibata︶です。この記事では、Go言語のtestingパッケージに用意されている並列化の機能について説明します。 Go言語では、テストコードを作成するためのtestingパッケージが用意されています。一般に開発するソフトウェアの規模が大きくなるに従って、作成されるテストコードの量も多くなり、すべてのテストが終了するまでの時間も長くなっていきます。特に、データベースへアクセスするようなテストでは、データベースへの通信時間がテスト時間の多く占めますので、テストコードを逐次実行するよりは並列実行することで、テスト時間を短縮できます︵厳密には用語﹁並行﹂ですが、t.Parallel()メソッドの説明なので、この記事では用語﹁並列
    Go言語でのテストの並列化 〜t.Parallel()メソッドを理解する〜 | メルカリエンジニアリング

  • TypeScript誕生の背景 | TypeScript入門『サバイバルTypeScript』


    TypeScriptは、JavaScriptでも大規模なアプリケーションを開発しやすくすることを目的に開発されたプログラミング言語です。 確かにJavaScriptは元々、大規模な開発を想定した設計ではありませんでした。それでも、JavaScript自体が進化して、大規模開発に対応してゆけば良かったはずです。しかし、実際はそううまくは行きませんでした。代わりに、大規模開発の一部はTypeScriptが引き受けることになったのです。 なぜ、そうなったのでしょうか？その答えはJavaScriptの歴史にあります。TypeScriptが必要な発明で、そして、今もなお必要とされている理由が見えてきます。それでは、TypeScript誕生以前の歴史をひも解いていきましょう。 1990年代​JavaScriptの誕生​JavaScript誕生以前は、簡単なフォームのバリデーションをするのも、サーバーサ
    TypeScript誕生の背景 | TypeScript入門『サバイバルTypeScript』
    vanbraam
    vanbraam 2020/07/06
    TypeScriptを作ったMicrosoftへの配慮かもしれないが,JavaScriptのIE独自仕様という邪悪な存在がJavaScriptの停滞をもたらしたことに触れないのはダメでは
    リンク

  • 【JavaScript】本日未明、[ if - else ]さんが死体で発見され... - Qiita


    ﹁な、なんじゃこりゃあああぁあっtっt！！！！﹂ ・・・ ・・・ ・・・ 読みやすいコードを書きたい 複雑な条件分岐は、書いている本人も、後からそれを読む他人も非常に疲れるものです。 令和プログラマー*1である私自身、なるべく気を付けようと思っていますが、ついつい条件反射でif-elseを書いてしまいそうになります。 ︵*1: 令和になってからプログラミングを知った人。初心者のこと。︶ if - elseを使わない条件分岐のレパートリーを増やす if - else文が絶対ダメということでは決してありません。 たくさんのレパートリー、つまり引き出しを持っておけば、適切な読みやすいコードをかける可能性が上がるかなと思うのです。 文と式 JavaScriptには﹁文﹂と﹁式﹂があります。 この2つの違いを意識することが重要ではないかと思います。 ﹁文﹂は、マシンへの命令です。 ﹁式﹂は数学的な値
    【JavaScript】本日未明、[ if - else ]さんが死体で発見され... - Qiita
    vanbraam
    vanbraam 2020/07/05
    3項演算子,evilとする人もいて,Goでは不採用になってたりするので,安易に勧めて良いのだろうか? 最低限Bob PikeやKen Thompsonに喧嘩売る覚悟が必要では?; つまらない話だが"死体"は故人が未特定の場合. 特定済の場合は"遺体"
    リンク

  • 世界は60年前の言語で動いている。米コロナ失業申請クラッシュでCOBOL使いの古兵が大忙し


    世界は60年前の言語で動いている。米コロナ失業申請がクラッシュ、COBOLの古兵が大忙し2020.04.17 22:0039,477 Joanna Nelius - Gizmodo US ﹇原文﹈ ︵ satomi ︶ コロナでギークが一番驚いたのがこのニュース。 失業給付金の申請者が史上最悪の1680万人に達して全米で業務システムがクラッシュ！ 化石のプログラミング言語COBOLを操る古参プログラマーが現場の最前線に駆り出され、﹁こんなこともあるんだな…﹂、﹁コロナって計り知れないな…﹂とIT業界を驚嘆させています。 絶滅すると言われ続けて60年COBOLは1959年、インターネットが生まれる遥か以前のメインフレーム時代に生まれたコンピュータ言語です。大学で教わるようなものではなく、使いこなせるのは現場で覚えた生き残りの人たちだけ。完全自動処理ではなく、手動で実行する処理も多く、早くから
    世界は60年前の言語で動いている。米コロナ失業申請クラッシュでCOBOL使いの古兵が大忙し
    vanbraam
    vanbraam 2020/04/20
    Cだって1972年生まれ,即ち50年弱前の言語なんだが. "60年前"という数字をタイトルに入れて煽るのは馬鹿げている
    リンク

  • 型なし言語のための型

    富山Ruby会議01

    型なし言語のための型
    vanbraam
    vanbraam 2019/11/05
    Rubyでdebugした時に型情報がない為に苦しんだ(メソッドの引数型が不明,call graphが作れない)ので,型は計算機の型検査の為だけでなく,コードを読む_人間の為_にも重要.そこがわかってないと導入しても余り役に立たないと思う
    リンク

  • ウワサのBlawnを触ってみた - Qiita

    program = block block = lines lines = line | lines line line = line_content EOF | line_content END | definition | import import = "import" STRING_LITERAL EOL line_content = expression definition = function_definition | class_definition | c_type_definition | global_definition | c_function_declaration function_definition = "function" identifier arguments EOL block return_value EOL | "function" ident

    ウワサのBlawnを触ってみた - Qiita
    vanbraam
    vanbraam 2019/10/26
    こういう分析がちゃんとできる人羨ましい;コンパイル時間が指数関数的に伸びる,という話,他の言語(例:Golang)で同様のコードをコンパイルするとどうなるのだろう?
    リンク

  • GitHub - Naotonosato/Blawn: Pleasant Programming Language.

    A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

    GitHub - Naotonosato/Blawn: Pleasant Programming Language.
    vanbraam
    vanbraam 2019/10/23
    サンプルコードをチラと眺めた限りでは,PythonとRubyのハイブリッドの様な見た目のコンパイラー言語,という印象;"@xxx function"ではなく"@function xxx"なのはなぜなんだろう?前者の方が他の部分と整合するのでは?
    リンク

  • プログラミング言語はひとつマスターすれば他もできる？ - t-hom’s diary


    プログラミングでは、ひとつの言語をマスターすれば、どんな言語でも使えると言われている。 この言説には賛否あるけど、ある意味正しくて、ある意味間違いだと思う。 より正確に言えば、新しく学ぶ言語と既にマスターしている言語に共通する概念についてはスムーズに移行できるということだ。 たとえば変数・分岐・繰り返し・比較演算なんかは、大半の言語が備えている共通概念である。言語によって作法やスタイルが異なるだけで考え方は同じなので、新しく学習する言語でこれらを使いこなすのは難しくない。 仮にVBAを100%マスターしているなら、Pythonの学習範囲はPython特有の部分だけで済む。 まあそうは言ってもなかなか一つの言語をマスターするのは難しい。 VBAの学習割合が少なければ、Pythonをマスターするための学習範囲はより広くなる。 じゃあまずはVBAを極めよう！と考えるかもしれないがそれも早計である
    プログラミング言語はひとつマスターすれば他もできる？ - t-hom’s diary
    vanbraam
    vanbraam 2019/09/17
    「_2つ_使えれば_だいたい_他も何とかなる」じゃないかな.1つしか知らない人は(computer scienceを先に学んだ人を除いて)"共通概念"という概念をまず理解する必要がある
    リンク

  • おそらく先がない5つのプログラミング言語？ - YAMDAS現更新履歴


    おそらく先がない5つのプログラミング言語、といういろいろと怒りをかいそうな記事だが、どうせワタシが愛するC言語なんかがまたやり玉に挙がってるんだろうと見たら、一番最初に Ruby が挙がっている…… この記事は TIOBE や RedMonk のプログラミング言語ランキングに Dice 独自の求人票情報を加味してるようだが、Ruby は落ち目という認識らしい。うーむ。 それ以外には Haskell、Objective-C、R、そして Perl が挙げられていて、この手の記事の定番といえる Perl、Swift 誕生後やはり定番である Objective-C はそうですかという感じだが、ビッグデータの時代に人気を高めたR言語ですら、Python に追いやられつつあるというのはそうなんでしょうね。 それにしても Ruby が先がないという意見には異論が出るだろう。ネタ元は Slashd
    おそらく先がない5つのプログラミング言語？ - YAMDAS現更新履歴
    vanbraam
    vanbraam 2019/08/06
    こういう記事(特に参照されてる元記事のようなやつ)を真に受けて,勉強する言語を決めるような人って,だいたいプログラマーとしてはダメな印象.プログラミング言語は必要に応じて学んで使い分けるものでしかない
    リンク

  • Microsoftが「Rust」言語を導入、安全性以外の理由あり（続報）


    Microsoftが﹁Rust﹂言語を導入、安全性以外の理由あり︵続報︶‥性能や安全性以外にも評価あり Microsoft Security Response Center︵MSRC︶は、C／C++に代わるシステムプログラミング言語の最有力の選択肢として﹁Rust﹂を挙げ、その理由を解説した。合わせてMicrosoftのような大規模なコードベースを持つ企業にとっての課題も示した。 なぜメモリ安全性と性能の両方が必要なのか MSRCによると、メモリ安全性を備え、Microsoft社内外で広く使われている言語は数多い。﹁C#﹂や﹁F#﹂のような.NETに対応した言語の他、﹁Swift﹂﹁Go﹂﹁Python﹂、Rustなどがある。 だが、システムプログラミング言語はOSカーネルなど、他のソフトウェアの動作基盤となるシステムの作成に使うものだ。CやC++が提供するような速度と予測可能なパフォーマ
    Microsoftが「Rust」言語を導入、安全性以外の理由あり（続報）
    vanbraam
    vanbraam 2019/07/25
    相互運用性はむしろ目指しちゃダメなのでは?
    リンク

  • アロー関数はthisを束縛しないとかいう謎文言について考える - Qiita

    ES6で導入されたアロー関数式は従来のfunction式の代替構文ではあるものの、純粋な糖衣構文ではありません。 特にthisの扱いが異なることは有名です。 具体的にどう違うのかと言うと、アロー関数のthisは宣言時のスコープにおけるthis固定である一方、function式におけるthisは呼ばれ方によって決まります。 加えてアロー関数のthisはapplyやcallで上書きすることは出来ませんし、bindで新しい関数を作っても上書きされません。 「アロー関数はthisを束縛しない」 この特徴に対し、「アロー関数はthisを束縛しない」という説明がよくされています。 が、この文言よく意味が分かりません。 字面やthisの動きだけ見ると、アロー関数の方がthisの値が変わらないわけでより値を束縛してそうに見えます。 出所と原文 おそらく、この文言の出所はMDNかと思われます。 アロー関数式

    アロー関数はthisを束縛しないとかいう謎文言について考える - Qiita

  • PEG Parsers

    Some years ago someone asked whether it would make sense to switch Python to a PEG parser. (Or a PEG grammar; I don’t recall exactly what was said by whom, or when.) I looked into it a bit and wasn’t sure what to think, so I dropped the subject. Recently I’ve learned more about PEG (Parsing Expression Grammars), and I now think it’s an interesting alternative to the home-grown parser generator tha

    vanbraam
    vanbraam 2019/07/24
    まだ冒頭しか読んでないが,Pythonのparser generator (pgen)をPEGに置き換える(事を検討する)という話? by Pythonの父
    リンク

  • /blog/2019/07/we-need-a-safer-systems-programming-language/

    /blog/2019/07/we-need-a-safer-systems-programming-language/

  • PHP End of Life (a reminder)

    As of December 2018 PHP 5 and 7.0 became End of Life. It is now July 2019 and up to 74% of PHP powered sites in the top 1 million are running software that is End of Life. This means there is no support and more importantly if new vulnerabilities are discovered, there will be no security fixes released. Upgrades do take work and major updates can take even more work. People are busy and the reluct

    PHP End of Life (a reminder)
    vanbraam
    vanbraam 2019/07/20
    このコメントを書いてる時点で5系全て及び7.0はEoL.なので5系使おうとする新規プロダクト/プロジェクトがあったら全力で止めるべし
    リンク

  • Microsoft、安全で高効率のプログラミング言語として「Rust」を高く評価


    Microsoft、安全で高効率のプログラミング言語として﹁Rust﹂を高く評価‥メモリ破壊バグを避けるには Microsoft Security Response Center︵MSRC︶は、ソフトウェアのセキュリティ確保と効率性の両方の要件を満たす最も有望なシステムプログラミング言語の一つとして、﹁Rust﹂を高く評価した。メモリ破壊バグをそもそも作り込まないことでセキュリティを確保できるという。
    Microsoft、安全で高効率のプログラミング言語として「Rust」を高く評価
    vanbraam
    vanbraam 2019/07/20
    Rust,何かメジャーなOSSプロダクトで採用されたら火がつくと思うし,自分も触る様になりそう
    リンク

  • LISP in Two Days with Rust - Plingdollar

    LISP in Two Days with Rust 10 Jul 2019 As a sidetrack from the development of my programming language I’ve spent some time developing a LISP. The plan is to use the language as a testing ground for experimentation with transforming an AST in Rust. The syntax of LISP is simple and was developed to be easy to parse. I figured it would make a good starting point for an experimental compiler. The lang

    vanbraam
    vanbraam 2019/07/20
    RustでLisp-likeな言語を作る話.プログラミング言語屋さんは呼吸する様にLispを作るので凄い&怖い;斜め読んだだけなので必要/興味に応じて後で読む
    リンク

  • 還暦COBOLはお荷物なのか？


    1959年に誕生したプログラミング言語のCOBOL︵Common Business Oriented Language︶は、2019年で生誕60周年を迎えた。人でいえば還暦や定年に当たり、これから第二の人生を歩んでもおかしくない年数である。このままひっそりとした余生を過ごすと思いきや、最近COBOL関連のニュースに事欠かない。 例えば、2019年1月24日には情報処理推進機構︵IPA︶が基本情報技術者試験を見直し、COBOLを午後試験の選択言語から外すことを発表した。また、厚生労働省の毎月勤労統計の問題も見過ごせない。厚生労働省が公表した報告書によれば、過去に不適切な調査が行われた原因はCOBOLエンジニア不足による﹁プログラムのチェック不足にある﹂という。 最近のCOBOL関連ニュースには、何かとネガティブなイメージが付きまとう。まるで﹁お荷物﹂といった扱いだ。COBOLエンジニアが少な
    還暦COBOLはお荷物なのか？
    vanbraam
    vanbraam 2019/03/04
    よく言われる「仕様書が残ってない」等はプログラミング言語の責任ではない;自動テストの仕組みがないのは現代言語としてはかなりマイナス.記事に書かれてる"課題"は的外れ感強い
    リンク

  • COBOLってこんな言語


    日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。 https://anond.hatelabo.jp/20190205192741 COBOLは本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyやPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルなデータ処理を想定している感じ。 SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通はJavaやRubyで全体の流れを記述してデータベース入出力をSQLで書く。
    COBOLってこんな言語
    vanbraam
    vanbraam 2019/02/07
    あと地味にCOBOLは数値を十進で扱うのが普通なので,浮動小数点数由来の誤差問題を考える必要がない点も,お金を扱うシステムで重宝された理由だと思ってる
    リンク

  • 本物のプログラマはPascalを使わない


    つい3年ほど前まで、ネット上で伝説の投稿﹁本物のプログラマはPascalを使わない﹂を読むことが出来たのだが、今はマニアックに日本語訳を探さないと読めなくなってしまった︵原文は今でもネット上で参照可能︶。 私の記憶が確かならば、日本語訳が月刊﹃bit﹄というコンピュータ雑誌に85年頃？に発表されたと思う。当時の私はまだ少年で、プログラミングの師匠︵ソフトハウスの正社員︶から﹁読んでみろ﹂と読ませてもらった記憶があるが、当然半分も理解出来なかった。 そんな私もSEとしては老人と言われるような中年になり、昔を知らない若いエンジニアや若いエンジニア志望の人が非常に多くなった。温故知新と言うが、当時を知る人や、若い人にも読んでもらえれば幸いだ。 はじめにMarch 24, 1983 Real Programmers Don’t Use PASCAL 本物のプログラマはPASCALを使わないEd
    本物のプログラマはPascalを使わない
    vanbraam
    vanbraam 2018/09/10
    半分ネタ,半分マジだと思うが,改めて読むとプログラミング言語は(FORTRANですら)計算機ではなく人間の為に進化して来たと感じる;最後の段落,FORTRANはHPC応用に一日の長がありvector演算処理が容易という話を聞いた事がある
    リンク

  • なぜGo言語はエラー返却に例外機構を使わないのか - 嵐の小舟より


    Go言語 FAQより引用すると 例外(exception)がない理由は?我々は、処理構造を制御するためのtry-catch-finally形式の例外処理機構によって、コードが入り組んでしまうと考えています。 とのことです。 うーん、これだけじゃよく分かりません。 知りたいのは、 ﹁例外機構が有用な場面﹂についてGo言語ではどのように対処するのか？ はたしてGo言語の他の機能を組み合わせることでカバーできるのか？ ﹁例外機構ではコードが入り組んでしまう﹂というのはどういうことを指しているのか？ 自分の探し方が悪かったら申し訳ないですが、 講演やら Effective Goやらでこういったことに言及している部分を見つけられなかったので、 調べた内容と自分の推測をまとめてみます。 結論としては 例外機構が欲しい場面は Go言語の他の機能でカバーできそう 例外機構によるエラー返却では、関数の
    vanbraam
    vanbraam 2018/08/31
    例外は大域脱出の方法の1つだと常々考えていたので,同じ様な観点から語る文章を知る事ができて嬉しい;例外が並列処理向きではない,というのは言われてみれば確かになぁ,と思った
    リンク
  • 1 2 3 4 5 6 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.