タグ

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

  • Goの準々標準ライブラリの探索 - Qiita

    フューチャーアドベントカレンダー21日目のエントリーです。全25話中、神回が25回あったウルトラマンZが終わってしまいましたね。全日人のうちの1億2000万人ほどがウルトラマンZロスでうちひしがれているころかと思います。 Goでは、Goをインストールしたときに一緒にインストールされるライブラリを「標準ライブラリ」と呼びます。また、golang.org/xなパッケージ群は準標準ライブラリと呼ばれます。準標準ライブラリには多彩なライブラリが含まれます。今ではもう家に入ってしまって、後方互換性のためだけに残っているパッケージも一部ありますが・・・ これ以外にも https://github.com/golang/ にはたくさんパッケージがあります。一部はgolang/xのものも入っているのですが、それ以外のものをここでは仮に準々標準ライブラリと呼ぶことにします。 golang.org/xのも

    Goの準々標準ライブラリの探索 - Qiita
  • 2019年末版:Chromebookを開発に使う - Qiita

    PySpaアドベントカレンダーのエントリーです。昨日はYesterdayでした。今日はTodayです。 ずっと開発や普段使いで使えるChromebookが欲しいと思っていました。勉強会の発表で使ったりするので、きちんと技適が通ったやつで、性能がまとも(以前ATOMベースのマシンにLinux入れたけど遅くて使う気になれなかったので)なやつを待ち望んでいました。 7月ぐらいからHPがChromebookを販売開始してくれました。気づいてから申し込んだものの、予想外に受注があったのか、納期が伸びに伸びて1ヶ月半近くかかりましたが、とても良いものだったので、今ではすっかりメインで使っています。 バージョンによって状況はまた変わってくるかもしれないので、タイトルに日時を入れました。これを書いた時点でのバージョンは78.0.3904.106(Official Build)(64 ビット)でした。 日

    2019年末版:Chromebookを開発に使う - Qiita
  • 事業会社とOSS - Qiita

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

    事業会社とOSS - Qiita
  • Python 3.7とVisual Studio Codeで型チェックが捗る内作Pythonアプリケーション開発環境の構築 - Qiita

    PySpa統合思念体です。 Pythonの開発環境の最新の環境の構築に挑戦してみたら、いろいろ型チェックとかできるようになって面白かったのですが、まとまった情報がなかったのでまとめてみます。基的にはmacOSでやっているけど、Python体のインストール以外には使用しているツール類はOS依存のものは使っていないため、パスや環境変数の設定を読み替えれば他の環境でも使えると思います。もし他の環境で注意すべきポイントがあったらお気軽に編集リクエストください。 エントリーは @aodag と @moriyoshi 、 @knqyf263 の情報提供により完成しました。ありがとうございました。 タイトルの意味 タイトルは文の想定状況を過不足なく状況をお伝えするために色々制約を加えています。「内作アプリケーション」と書いているのは、配布しているツールとかでなければ、特定のバージョン1つを選択し

    Python 3.7とVisual Studio Codeで型チェックが捗る内作Pythonアプリケーション開発環境の構築 - Qiita
  • イマドキのJavaScriptの書き方2018

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

    イマドキのJavaScriptの書き方2018
  • pyenvが必要かどうかフローチャート - Qiita

    pyspaの統合思念体の渋川です。 「pyenv使いましょう!」系の記事、全部ゴミ — Yoshifumi YAMAGUCHI (@ymotongpoo) September 29, 2016 これはpyenvがダメではなくて、pyenvをとりあえずインストールしておきましょう記事がダメという意味だそうです。すでにとんぷーが5年前にこの問題について書いています。これを読んで分かる人には不要です。 この記事では「便利」と「必要」は分けて考えています。後者にフォーカスしています。 前提知識 Environment Isolation Tool(環境分離ツール)というカテゴリの開発補助ツールがあります。pip install Sphinxとか書いたら、ライブラリはグローバル空間に入っちゃいます。複数バージョン入れられません。そんなときに使うのが、この環境分離ツールです。最近はいろいろな言語がこれ

    pyenvが必要かどうかフローチャート - Qiita
    lugecy
    lugecy 2017/12/03
  • GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか - Qiita

    PySpa統合思念体です。チャットで話をしたことのまとめです。何人かで雑に話をしたことのまとめで、特定の誰かの発言というわけではなく、一種の怪文書です。 さて、GraphQLが世間を賑わせ始めています。Facebookが開発し、GitHubも機能提供をし始めました。GraphQLはRESTの未来か?みたいな論調もありますが、新しいものが出てくると既存のものをサンドバックにして「まだそんな古いの使ってやがるのかよwwwww」みたいな煽りをするのはもはやウェブ界隈の風物詩になっていますが、そういう信者発言をして「ああ、あいつまた踊らされてるな」「あいつ技術を見る目がないな」みたいに思われないように、少し冷静にGraphQLの立ち位置や、今後予想される流れについて考えてみます。 LSUDsとSSKDs WebAPI The Good Partsでも紹介されていた概念として、Netflix社のAP

    GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか - Qiita
  • JavaScriptはなぜトレンドが毎年変わると思われていたのか - Qiita

    JavaScriptはなぜトレンドが毎年変わると思われていたのか JavaScriptのエンジニャーは口を開くたびに出てくるツール名が違う、いつも環境設定をしている、みたいな話をよく聞きます。実際、それを揶揄するようなエントリーが人気だったりします。 とはいえ、JavaScriptを実際に使い込んでいる人は別にそんなに大きな変化だと思っていない節があって、台風は外周部ほど風速が速い、みたいな印象を感じます。 カンブリア紀のJavaScript ウェブサイトをパカパカ動かすための言語でした。DHTMLです。FireBugが出る前のJavaScriptを開発していた人類は、念力デバッグを駆使していました。あるいはalert()。 三畳紀のJavaScript prototype.js、jQuery、Closure Compiler、YUI、mochikit、Ext.jsなどの時代。JavaSc

    JavaScriptはなぜトレンドが毎年変わると思われていたのか - Qiita
  • サーバーサイドレンダリング不要論 - Qiita

    サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け

    サーバーサイドレンダリング不要論 - Qiita
  • オレの最弱のES6開発環境 - Qiita

    ブラウザのES6サポートが急速に良くなってきています。社内ツールとかElectronとか、ブラウザの普及率を気にしなくていい環境ならそろそろ使えるのではないかと思って調べたり試してみたりしています。 更新 https://caniuse.com/#search=es6 http://kangax.github.io/compat-table/es2016plus/ これを見るともうほぼ実装は完了していますね。Node.jsも対応していますし使えるブラウザが限定できるならもはや変換なんかしなくても大丈夫。注意点としては以下の2つ。 IE11は渋い ES6 modulesはまだまだ ソースをES6で書いて、結果もそのままES6という手抜き開発に使えるツールのメモです。手抜きなので、おそらく経年変化の影響はほとんどないはずです。対象としてはブラウザだったり、ElectronでのSPA開発です。

    オレの最弱のES6開発環境 - Qiita
  • Go最後の秘宝「GUI」を探しに行く - Qiita

    Golangができること、むしろ「得意」と言われるものはすでにたくさんあります。 クロスコンパイルが得意だし依存が少ないバイナリができるから、いろんな環境で使えるコマンドラインツールを書くにはGoがいいよ パフォーマンスが高いし文字列処理もやりやすいので、高速なAPIサーバが得意。gRPCでもHTTP/2でも Webアプリケーション・フレームワークも増えてきていてウェブサービス作れるよ ビルドシステムとパッケージマネージャ内蔵なので、gitから簡単にパッケージをダウンロードしてきたり、◯makeコマンドとか◯runtとか◯owerで消耗しなくて済む gopher.jsでJavaScriptにもなる 逆に今まであまり良い解がなくて、「Goにはちょっと不向きだね」と言われ続けていたのがGUIです。鳴り物入りで出てきたGXUIが開発が止まってしまい、それと同じぐらいにshinyというものが開発が

    Go最後の秘宝「GUI」を探しに行く - Qiita
  • 1