タグ

ブックマーク / qiita.com/shibukawa (7)

  • 事業会社とOSS - Qiita

    最近、社内でよく話をする内容についてまとめました。 企業がOSS化するといろいろメリットがあると思っていて、社内でもそこのコンセンサスはうちの技術横断部門のメンバー間では取れていたりするのですが、自社以外の人とかと話をする時もあるので、いろいろまとめておきます。 なお、この文章では業をOSSにしつつビジネスを回そうみたいなElasticsearchとかMongoDBとかMySQLみたいな話題はとりあげず、業が別にある会社がOSS化する、という部分に特化した話です。 9/13に追記 よく言われるメリットとデメリット メリットは、公開することで開発が自然と進み、コスト削減になる。一方でノウハウの流出などのデメリットがある、みたいなトレードオフ、という理解をしている人が多いようです。 コストは削減にならない OSS化したら多くの人に使ってもらいたいですよね?というのは考えるわけですが、その「

    事業会社とOSS - Qiita
  • 20年でソフトウェア開発の景色はどのぐらい変わったのか? - Qiita

    PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてあるないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺伝子を受け継いでいるのが多いよな、そういえば当時から見て今ってどう変わっているのかな、という話題に。せっかくなので20年前を思い出しつつ、当時と今でどういう風に変わってきたのか適当にまとめてみます。 20年前の状況 XP白こと、eXtreme Progra

    20年でソフトウェア開発の景色はどのぐらい変わったのか? - Qiita
  • Python 3.7とVisual Studio Codeで型チェックが捗る内作Pythonアプリケーション開発環境の構築 - Qiita

    ちなみに、3.7としているけど、ほぼ3.6でも問題なくいくかと思います。 エントリーの方針 このエントリーではPython 3.7で動くアプリケーションの開発環境を作りますが、その過程で必要なツール(Python体、pip、pipenv)をそれぞれの場所にインストールします。とりあえず次の方針でやります。Python体以外はPythonのエコシステムでやっていきます。イージーよりはシンプルという方針です。 管理者権限が必要なシステムへの変更は最低限にする。ユーザー権限で入るものはユーザー権限で入れる。 PATHや環境変数への変更も最低限にする。 Python体以外はOS固有のツールには依存しないようにする。 curlで取ってきたスクリプトをパイプでsudoで実行するみたいな頭に虫が湧いているようなマジキチなことはしない。 Python処理系環境構築 (システムごとに1度だけ実行)

    Python 3.7とVisual Studio Codeで型チェックが捗る内作Pythonアプリケーション開発環境の構築 - Qiita
  • チョットできるGoプログラマーになるための詳解GoDoc - Qiita

    上の2つがCLIで、下の2つがブラウザです。歴史的な経緯を見てみましょう。 〜1.1: go docはバンドルされているツールで、ソースもgo体に同梱 1.2: go docは別のリポジトリにわけられてgodocになり、go体から外れた 1.3: godocで-analysisオプションが追加 1.5: 新しい"go doc"コマンドがgo体に同梱 1.11: godocがウェブだけになるため、go docを使えというアナウンスが出るように 1.12: godocが-httpだけをサポートしてCLIの機能は削除予定 1.13: godocのwebサーバーが同梱されなくなって手動でのインストールが必要に 1.13~: 既存のgodoc.orgから、go modのプロキシサーバーの情報をもとにドキュメントをホスティングするpkg.go.devが運用開始 わかりましたか?よくわかりませんよ

    チョットできるGoプログラマーになるための詳解GoDoc - Qiita
  • イマドキのJavaScriptの書き方2018

    PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」(よりよい代替がある)というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前のやウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい

    イマドキのJavaScriptの書き方2018
  • PythonからJavaScriptに桁落ちなしで浮動小数点数のデータを移す - Qiita

    Pythonで作成した64ビットの浮動小数点数の数値を、そのままJavaScriptに持って行きたいことってありますよね?どっちもIEEE-754の64ビット(符号1ビット、仮数52ビット、指数11ビット)です。 そのまま渡せたらいいんですが、ダンプして10進数で出すと丸めとか行われてしまってうれしくありません。 このエントリーでは、誤差なしでそのまま浮動小数点数渡す方法を詳解します。 実際には、JavaScriptはECMAScriptの仕様で決められていて、PythonはCのdoubleと同じなので、結果としていまあるほとんどのOSの環境で同じフォーマットになっています。 Pythonで浮動小数点数バイト表現の文字列でエクスポートする float64はstruct.packを使ってバイト配列にして、その後formatで16進数の文字列にします。ネットワークバイトオーダーで出しています。

    PythonからJavaScriptに桁落ちなしで浮動小数点数のデータを移す - Qiita
  • オブジェクト指向と20年戦ってわかったこと - Qiita

    この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則? 3原則じゃなくて4では?みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav

    オブジェクト指向と20年戦ってわかったこと - Qiita
  • 1