タグ

ブックマーク / qiita.com (336)

  • Scala2.13の新機能をいくつかピックアップ - Qiita

    Scala2.13はコレクションライブラリの再構築がとにかくでかくてそれ以外はどうなんだろ、、と思ってリリースノートを眺めていたところ意外と色々あるなということがわかった。 主に普段の開発ですぐ使えそうな便利機能を拾ってみました。 リリースノート: https://github.com/scala/scala/releases/tag/v2.13.0 ただし網羅性は保証しません、オレオレピックアップであることにご注意を。 数値 数値リテラルでのアンダースコア区切り Java7で書けるようになったアレだ。 val s"Hello, $name" = "Hello, James" println(name) // "James" val TimeSplitter = "([0-9]+)[.:]([0-9]+)".r val s"The time is ${TimeSplitter(hours,

    Scala2.13の新機能をいくつかピックアップ - Qiita
  • 1年間本番環境で WebAssembly ( by Emscripten )を使ってきた中で生じた問題とその解決策 - Qiita

    1. 今 WebAssembly を生成するなら何から作るか WebAssembly の人気がとどまることを知らない昨今ですが、みなさんはどうやって WebAssembly を生成しているでしょうか。 自分の観測範囲では、RustGo で書いたコードから生成したり、 AssemblyScript を使って TypeScript などから作ったり、 Emscripten を利用して C/C++ で書いたコードから作ったりしているのが多い印象です。 このうち、番環境で長らく WebAssembly を運用してきた身としては、今の段階では Emscripten、または自分では使っていませんが AssemblyScript を利用する方法が良い気がしています。 というのも、主要ブラウザが WebAssembly をサポートしてくれているとはいえ、まだまだ WebAssembly がサポート

    1年間本番環境で WebAssembly ( by Emscripten )を使ってきた中で生じた問題とその解決策 - Qiita
  • Android開発はFlutterでやる方がいい説 - Qiita

    はじめに クロスプラットフォームとして語られるFlutterですが、実は、「Android開発だけでもFlutterでやった方がよくね?」 となんとなく思い始めています。 「FlutterってGoogleAndroid開発を再定義した画期的なものになるんじゃないか」と。 自分は、おっさんなので古い話をしますが、Java開発でEJB2が存在していた頃です。まだ、バージョンが1.1になったばかりのSpring Frameworkを使った案件にたまたま参加したときの衝撃と同じなんです。「何これ? めっちゃわかりやすい。標準のEJBなんて駄目じゃん。」 今ではEJBは廃れ、Springがデファクトスタンダードになっていますよね。 ただ、使ったことがない人に伝えるのは当に難しく、納得できない人も多いはずです。 自分でもなんでそう思うのかうまく伝えられる気もしないのですが、言語化してみます。 自分

    Android開発はFlutterでやる方がいい説 - Qiita
    petitviolet
    petitviolet 2019/03/28
    flutter面白そうという感想
  • 非同期 IO について - Qiita

    おしながき C10K 問題 について 非同期 IO とは何か async-await 非同期 IO のこれから 1. C10K 問題 について 時は 2002 年 Web 勃興期 牧歌的時代の終わり HTTP サーバ 10000 クライアントからの同時接続 どう実装するか 当時の Web サーバ Apache クライアント毎に 1 プロセス クライアント毎に 1 スレッド クライアント毎に 1 プロセス 10000 プロセス も起動したら OS が死ぬ CPU|メモリ が足りない PID の上限 etc... クライアント毎に 1 スレッド 10000 thread も起動したら OS が死ぬ CPU|memoryが足りない thread数の上限 virtual memory の上限 etc... これからの時代(2002年当時) nginx 複数の thread で複数の client

    非同期 IO について - Qiita
  • 変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita

    この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ!」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

    変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
    petitviolet
    petitviolet 2019/01/02
    図がわかりやすい
  • 組織の新言語導入(JS→TypeScript→Elm)で成したかった組織づくりの話 - Qiita

    Fringe81のリレー記事ということで、たまにはお仕事での意思決定の話でも書いてみようかと思います。 僕はここ4年ほど、フロントエンド技術選定をしてきましたが、今回はその中でも「言語」に関して、どういう軸を作ってやってきたのかということを振り返ってみたいと思います。 (生産性が高いもの選びという観点は前提だと思っているので記事ではあえて除外します) で、何を大事にしていたのかなーという事を改めて言葉にしてみると、僕は技術選定を通して、「壁のない組織」 というイメージをずっと追っていた気がします。 今日はその視点で各技術を入れてきた目的と結果を書いてみたいと思います。 すでに技術選定している方や、これからやりたいなーと思っている方の参考になればうれしいです。 ES5時代 よくうちの会社では社内全kaエンジニア勉強会を実施しているのですが、その時に一つ感じていた大きな壁がありまして。 僕

    組織の新言語導入(JS→TypeScript→Elm)で成したかった組織づくりの話 - Qiita
  • Scala 2.13 のコレクションライブラリの設計について - Qiita

    はじめに Scala (v2.12) のコレクションのクラス構造が謎だなとはわりと思っていて(Xxx と XxxLike と GenXxx ってなに〜)、The Architecture of Scala Collections あたりを読んでまとめようと思っていました。 しかし、v2.13 でコレクションに入る(正確に言うと、 2.13.0-M4 で入った)変更をドキュメントやソース読みつつ調べていたら、ほんとうに大きな変更だなあ、なんだかここでまとめてももったいないなあ、という気持ちになってきたので 2.13 のコレクションについてざっくり調べてみることにしたのでした。 この記事では、scala-lang.org にある、コレクションライブラリの設計概念について書かれているドキュメントをざっくり訳しつつ 2.13 でのコレクションの設計などについて理解を深めようと思います。 TL; D

    Scala 2.13 のコレクションライブラリの設計について - Qiita
  • KubernetesにおけるPodの初期化処理 - Qiita

    これはなに? 記事ではKubernetesにおけるPodという形でアプリケーションを起動する際、どのように初期化処理を実行できるのかについて取り上げる。 なお終了処理は触れない。 lifecycle.postStartを使う spec.containers.lifecycle.postStartを利用すればライフサイクルにおける"起動"直後に何かしら処理を差し込むことが可能。 これはPodの起動、ENTRYPOINTやCMDと同時(非同期)に実行される。 ドキュメント: Attach Handlers to Container Lifecycle Events - Kubernetes postStartで初期化処理をするdeploymentのyaml例を書いてみる。 サンプルのファイルはGithubにおいてある。 apiVersion: apps/v1 kind: Deployment

    KubernetesにおけるPodの初期化処理 - Qiita
  • ScalaをGraalVMで動かす&ネイティブイメージ化する - Qiita

    Scalaプログラマの観点からGraalVMを紹介、使ってみる。 GraalVM? GraalVMは、思い切り雑に紹介するとScala(Java)プログラムを高速化することが出来る(ことがある)らしい。 このあたりを読むともう少し詳しく書いてある。 https://www.graalvm.org/docs/why-graal/#for-java-programs 簡単にまとめておくと、特徴としては Javaを高速化 JITコンパイルになにかしら改良がしてあるとのこと。 Javaコンテキスト内で別の言語(JSやPython)を実行 Ployglotなアプリケーションを開発可能 Nativeイメージを作成 JITではなくAOTコンパイル の3点が挙げられている。 この記事では1と3に触れてみる。 2についてはEmbed Languages with the Graal Polyglot API

    ScalaをGraalVMで動かす&ネイティブイメージ化する - Qiita
  • フリーランスエンジニアの単価を決める - Qiita

    記事概要 書いた目的 フリーランスエンジニアの単価設定に「情報の非対称性」ある フリーランスは市場動向掴んで「売り手」になるべき エンジニア応援したい、優秀なエンジニア年収伸ばせば良いし、キャリアミスマッチしてるエンジニアは再構築すれば良い 読者想定はフリーランスエンジニア、qiitaに多そうだから投稿 記事の内容 1. 自分のプロフィールと単価を公開 前職年収900万円で、フリーランス日額6.5万円〜10万円 40社ぐらい営業して、1/3は話が進む 2. この単価設定にした根拠を説明 前職基準、採用市場、派遣、フリーランス市場、英語圏 3. 終わりに 「こんな人材求められてるんじゃないかな」、「こうしたらキャリア積めるかも」を記載 正社員に戻って修行するなら、開発チームが強い(CTOが役員として存在)イケてるWeb企業で正社員キャリア積むことを目指すべき フリーランスのままでも「チーム

    フリーランスエンジニアの単価を決める - Qiita
  • 無料のはずのGCEのf1-microインスタンスで11月だけ1円課金された理由 - Qiita

    2017年3月からGCEのf1-microインスタンスが一人1台無料になりました。私自身3月からずっと起動したままで運用してきて10月まで無料で使わせてもらっていたのですが、下記の通り11月は1円を請求されていました。 GCEのf1-microインスタンスは1ヶ月分(月の日数に応じて720時間もしくは744時間)のCPU利用が無料になるのですが、11月は721時間使っていたというのです。 課金された理由はサマータイムの終了 いい大人であれば1円くらい仕方ないなと思うところでしょうが、私は理由が気になって課金ログを確認してみました。すると、11/5だけ25時間分のCPUを使っていることがわかりました。アメリカの11月第1日曜日はサマータイム終了の日なので、実際に1日が25時間あるのです。 これがGoogleさんの意図通りかは不明ですが、おそらく考え漏れなんじゃないでしょうか。サマータイムって

    無料のはずのGCEのf1-microインスタンスで11月だけ1円課金された理由 - Qiita
  • GraphQLの認証をどこでやるか - Qiita

    GraphQLAPIを実装するにあたって、認証をどうするか。 GraphQL内部で認証する GraphQLの外で認証する 認証とスキーマ 参考: A guide to authentication in GraphQLApollo GraphQL Learn SangriaのAuthentication and Authorisationセクション ScalaでSangriaを使って実装を考える。 個人的な結論 認証はGraphQLの手前で実行する。 具体例としては、クライアント側は認証が必要な操作をする際にHTTP Headerに認証トークン的なものを入れて送る。 サーバ側はGraphQLの世界に入る前にHTTP Headerからトークンを取り出して認証を行い、ログイン中のアカウントを特定してCtxのプロパティに入れてGraphQL世界に渡す。 スキーマとしては、アカウントそのも

    GraphQLの認証をどこでやるか - Qiita
    petitviolet
    petitviolet 2018/07/16
    書いた
  • SangriaでGraphQLのinterfaceを扱うには - Qiita

    sangria-graphql/sangriaを使ってGraphQLAPIを実装する時にinterfaceをどうやって使うか、という話。 interface自体は特に難しい話ではないが、地味に動かなくて困ったので残しておく。 まとめ interfaceの実装自体はInterfaceTypeを使うだけ Field.fieldTypeにInterfaceTypeを与えるだけだとSchemeがエラーになる 解決策として Schema.additionalTypesあるいはInterfaceType.withPossibleTypesでそのinterfaceを実装したObjectTypeを与える UnionTypeを使う interfaceの実装としてのInterfaceType GraphQLの公式ページ: Schemas and Types | GraphQL いわゆるinterface的な

    SangriaでGraphQLのinterfaceを扱うには - Qiita
    petitviolet
    petitviolet 2018/07/01
    書いた
  • Kubernetesのエコシステムをまとめる - Qiita

    Kubernetesのエコシステムをまとめる(2018年5月時点) 日のGW中(2018年)にデンマークではKubeConを開催しているようでして、現地で参加している方々は羨ましい限りです。 KubeConの情報が日に届くのはGW明けだと思いますが、その前に昨今のKubernetesのエコシステムとかいろいろなことをまとめます。 <追記2018/05/13> KubeCon 2018 EUで公表された情報も追加しました。 <追記2018/06/08> チュートリアル、トレーニングを追加しました。 <追記2018/06/11> プレイグラウンドを追加しました。 <追記2018/06/19> MS Azure AKSがGAしました。 Kubernetesとは? Kubernetesはコンテナのオープンソースのオーケストレーションツールです。Dockerを使ってアプリケーションをデプロイ、運

    Kubernetesのエコシステムをまとめる - Qiita
  • DDDでエンティティ間の関連を「ロールオブジェクト」でスマートに扱う - Qiita

    はじめに 実践ScalaでDDD で発表した中で、エンティティ間の関連を「ロールオブジェクト」として定義する ことをお話ししましたが、スライドでは要約になっています。 実際にプロダクトでやってみて有効なパターンだと感じているので、改めて突っ込んで解説したいと思います。 なお、内容的には Scala をターゲットとしていますが、他の言語にも考え方は応用できると思います。 サマリ DDDで設計していると エンティティ と エンティティ の間に関連があり、その 関連に関するドメインの振る舞い と言うものが出てきます。 例えば 「ユーザー エンティティ」 と 「タスク エンティティ」 がある場合に、その間には 「タスクの作成者」 や 「タスクの担当者」 と言う関連があったりします。 そしてそれらの関連は「タスクの作成者は、タスクを削除する」や「タスクの担当者は、タスクを完了する」のような振る舞いを

    DDDでエンティティ間の関連を「ロールオブジェクト」でスマートに扱う - Qiita
  • [Scala]SangriaでUpdateCtxを使ってGraphQLの認証を実装する - Qiita

    ScalaGraphQLフレームワークのsangriaでUpdateCtxを使って認証処理を実装する。 使い方に注意点がいくつかあるが、まずは普通に動かすための方法について。 UpdateCtxを使って実装する 認証処理に関するドキュメントはLearn SangriaのAuthentication and Authorisationセクションにあり、「Resolve-Based Auth」として紹介されているようにUpdateCtxを使って実装してみる。 その前に、まずはsangriaを動かすための前提となるCtxおよび共通して使用する型を定義する。 色々実装が雑なのはサンプルのためなので目を瞑る。 コード全体像はGithubにpushしてある。 // ユーザー case class User(id: Long, name: String, email: String, password

    [Scala]SangriaでUpdateCtxを使ってGraphQLの認証を実装する - Qiita
    petitviolet
    petitviolet 2018/04/27
    書いた
  • kubernetesで動かすコンテナのヘルスチェック - Qiita

    この記事は何 タイトル通り。 kubernetes上でコンテナなWebアプリを動かす時に必要になってくるヘルスチェックや起動時のデータ読み込みをどうやって設定するか。 ドキュメントはこの辺り。 Configure Liveness and Readiness Probes | Kubernetes コンテナのヘルスチェックには2種類あり、livenessとreadiness。 簡単に説明するとこんな感じか。 livenessはコンテナそのものが立ち上がっているかどうかをチェックするもの readinessはリクエスト受け付け準備が整っているかどうかをチェックするもの

    kubernetesで動かすコンテナのヘルスチェック - Qiita
    petitviolet
    petitviolet 2018/04/01
    書いた
  • kubernetesで動かすソフトウェアの設定をConfigMapで記述する - Qiita

    まとめ nginx.confなどの設定ファイルをkubernetesのConfigMapで記述し、Volumeとしてマウントすることが出来る。 ドキュメントはこの辺り。 Configure a Pod to Use a ConfigMap | Kubernetes Volumes | Kubernetes 実際のyamlファイルはGistにある。 何が課題か kubernetesで動かすDockerコンテナ内にどうやって各アプリケーションが使用する設定ファイルを差し込むか、という話。 例えばnginx.confなどの設定ファイルをどうやって管理するか。 いくつか方法がある。 Dockerイメージの中に入れておく ADDした状態でdocker buildしておく ファイルにしておいてコンテナにVolumeとしてマウントする デプロイするホストのディレクトリをマウントする 永続ディスクを作成し

    kubernetesで動かすソフトウェアの設定をConfigMapで記述する - Qiita
    petitviolet
    petitviolet 2018/03/18
    書いた
  • Macでminikubeを使ってkubernetesクラスタを動かす - Qiita

    してminikubeを起動する。 そして、kubectlで認識されることを確認する。 $ kubectl config current-context minikube minikubeがdockerを内包している形になっているので、環境変数もろもろを書き換える。 ローカルのdockerとminikubeでDockerイメージを共有する minikubeがdockerを内包している形になっているため docker images (eval $(minikube docker-env) && docker images) では結果が異なる。 回避するには、eval $(minikube docker-env)してからdocker buildするなどして、minikube環境下Dockerイメージを作って登録するのが手っ取り早い。 あるいは、

    Macでminikubeを使ってkubernetesクラスタを動かす - Qiita
    petitviolet
    petitviolet 2018/03/17
    書いた
  • sbt pluginのつくりかた ~実装から公開まで~ - Qiita

    世間ではsbtはSimple Build Toolの略だという噂もありますが,ぶっちゃけ全然simpleじゃないです笑1 今回は試しにsbt-gcsというsbtのpluginを自作してみたので,これをベースに(私の思う)sbtのややこしい部分を解説しつつ,sbt pluginの開発から公開までの手順を紹介しようと思います! こんな人にオヌヌメ sbtのpluginを作って見たい人! sbtを使ったことはあるが次のコードがようわからんっていう人 前提 とりあえず筆者の環境は以下の通りでした. sbt 1.1.0 Scala 2.12.4 はじめに sbtは全然simpleではありませんが,ドキュメントはかなりしっかりしています. 公式ドキュメント厨の方は,ここ2つを読めば基プラグイン開発には困らないはずです! Plugins Best Practice Plugin開発 sbt plugi

    sbt pluginのつくりかた ~実装から公開まで~ - Qiita