kobito-oss のソースの読み方 - Qiita
メインの開発者として、備忘録を残しておく。 どんなものか試したい人は、 https://mizchi.github.io/kobito-oss/ で、IndexedDBの許す5MBぐらいまでは試せる。 一応言っておくと、これは僕が退職するんでOSS化ってわけではなく、元々あった計画の前倒しです。時期が早まったのはある。 以下、どのようにコードを読むか。 念頭に置くこと 2年前 の技術選定のスタック Mac版Kobitoと仕様が違う。Kobitoと同期しない、Inboxという仮グループがある。 mizchi/arda electron 以前の atom-shell 時代の互換コードが一部残ってる 細々とバグ対応はしつつ、あんまり依存パッケージのメンテ出来てなかった 公開にあたって、個別のタスクの綺麗さより、ビルドできるの優先した とりあえず yarn で固定して yarn upgrade-i
「することができる」は有害と考えられる - Qiita
「することができる」とは 技術文書を読んでいると「することができる」「することが可能である」という表現を目にします。実はこの「することができる」という表現は冗長なため有害、つまり多用すべきでないという考えがあります。 気になって「することができる」についてGoogleで検索してみました。結果、「することができる」という表現について書いたブログ記事をいくつか見つけました。以下、発見したブログ記事の一覧です。 読みやすい文章の極意は「修飾語」にあり 読みやすい文章を書くために心がけたい１０のポイント 感性工学的テキスト商品学～書き言葉のマーケティング 列挙したブログ記事の全てで「することができる」を多用しないように警告しています。 「することができる」を自動で検知 私も「することができる」「することが可能である」のような冗長表現をできるだけ利用しないように気をつけています。「することはできる」
AWS Batch とは何か - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? AWS re:Invent 2016 で発表された AWS Batch。 語感から、誤解されるサービス No.1 な気がします。 定時バッチなどとは何がどう違うのかをメモ。 機能概要 以下公式資料とドキュメント、実際さわってみた所感を合わせて。 AWS Batch – 簡単に使えて効率的なバッチコンピューティング機能 – AWS AWS Black Belt Online Seminar「AWS Batch」の資料およびQA公開 結局何なのか 科学技術計算・ハイパフォーマンスコンピューティング用途で真価を発揮する、 大規模なスケール、ジ
devops - Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた - Qiita
Feature Toggles Pete HodgsonさんというThoughtWorksの方が書かれたFeature Togglesという記事が面白かったので翻訳してみました。 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016の記事で取り上げていただいた通り、マイクロソフトの内部の開発では多くのフィーチャートグルが使われています。このことをより深く理解したいと思って個人的に翻訳したものを公開します。私的な自分が理解する用の翻訳でありますので、その辺はご考慮いただければと思います。Pull Requestは歓迎いたします！ 概要 フィーチャートグルズ(Feature Toggles)は、とてもパワフルなテクニックだ。チームがコードを変更することな
「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
地域技術コミュニティの役割 - Qiita
jp.freebsd.orgのサービスが終わるらしい。freebsd.orgの地域別サブドメインをなくすという方針によるものだそうだ1。 これを機会に（FreeBSDに限らないが）地域技術コミュニティの役割について私見に基づく（多分寝言以下の）ポエムを書いてみようと思う。 技術の全地球化 インターネット他多くのメディアのおかげで、技術は全地球的(global)に広がりつつある。特定の国や地域に依存することなく情報を配布する仕組みは着々と世界レベルで整いつつある2。しかもその世界レベルの情報配布は、ミラーリング等の地域リソースの協力ではなく、ネットワーク層の世界的な高速化、そしてCDNなどミラーリングそのものを隠蔽する仕組みの普及により、一次配布先から直接行われるようになりつつある。 言い換えるなら、この前提を受け入れられない技術は、衰退していくしかなくなりつつある。書店の取次、地域別代理店
ほころびていくコミュニティとなかなかできない世代交代、そしてさよならアドベントカレンダー - Qiita
追記: 以下の文章に対して佐藤広生先生が自らの体験に即した意見を述べておられます。ぜひ一読をお勧めします。 昨年2015年にjp.freebsd.orgドメインの終焉に伴い地域技術コミュニティの役割というポエムを書いた。今年のはその続編である。こんなポエムを書くのも今年で最後にしたい。 51歳を越えたオッサンがPort maintainerをやる状況 今年2016年は初めてFreeBSDのPort maintainerになった。devel/git-lfsとjapanese/dbskkd-cdbの2つについてである。どちらも自分の仕事に必要だったが、前のmaintainerが作業をしないままか、あるいは他の事情でmaintainer不在の状態になったか、という事情からである1。 Port maintainerをやること自身には異存はない。日本にもTeXLiveのPortsを仕切っておられる佐
Retty流『2200万ユーザを支える機械学習基盤』の作り方 - Qiita
みなさん、こんにちは。Retty CTO の樽石です。 この記事は Retty Advent Calendar 25日目です。メリークリスマス。 昨日は @ttakeoka の『MFIにむけてRettyの取り組み』でした。 今年も残りわずかになりました。いかがお過ごしですか？ Retty はこの １ 年でエンジニアがほぼ倍増しました。それによって、情報発信者が増え、Advent Calendar に参加出来るようになりました。みんな楽しそうにしていて、うれしいです。 Retty Inc. Advent Calendar 2016 - Qiita さて、今年最後の Retty Advent Calendar 記事を書くということで、はじめは １年のまとめ的内容にしようかと思いましたが、それでは平凡で面白くありません。そこで、ネタになりそうなマニアックな技術的記事で締めくくりたいと思います。
基本/詳細設計って呼び方やめませんか - Qiita
システムの規模がそこまで大きくない場合は、外部設計、内部設計だけでよさそうです。 ここまでで、「基本」「詳細」という呼び方ではいまいち分かりづらかった記述範囲がはっきりしてきたので、引き続き、これらの範囲内をどのように書くべきか考えてみます。 設計の 5W1H よく分からないものについて考えるときに、取っ掛かりとして 5W1H で考えてみるのは定石です。言うまでもありませんが 5W1H とは WHEN (いつ) WHERE (どこで) WHO (だれが) WHAT (なにを) WHY (なぜ) HOW (どのように) ですね。 このうち、WHEN と WHO はステークホルダーを追加した V 字モデルで明らかにしました。WHERE はあまり関係なさそうなので、残りの WHAT, WHY, HOW について考えてみましょう。 設計の WHAT 設計における WHAT とはどういうことでしょう
至高のDockerイメージ生成を求めて - Qiita
本稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stage buildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ
実録!!データ構造リファクタリング -- 僕とメッセージ機能の300日戦争 - Qiita
みなさんもきっとそうだと確信いたしておりますが、プログラマというのは、どういうわけか実装のちょろまかしには頭がまわるもので、今や丁寧なコードを書く人の鏡とまで言われるワタクシも、それはそれは手抜き方法ばかりうかんだものでした。 技術的投資のいくつかは、不本意ながら技術的負債になりまして、いろいろと世間様にもご迷惑をおかけした次第です。みなさんもきっとそうだと思いますが。 この話は、そんな「誰にでもある」小さな事件のひとつです。1 この記事は CrowdWorks Advent Calendar 21 日目の記事です。 昨日は @tmknom さんの 「アプリケーションアーキテクチャに関するポエム」 でした。 設計に関するトピックは幅広く、かなり広範な知識が求められますよね！早く DDD を読まねばという気分になりました（笑）。 さて、この記事は、著者がここ１年ほど携わった簡単なデータ構造の
JavaScript でも型チェックと契約による設計で安定した開発をする - Qiita
チーム開発をやっていると特定の処理を呼び出す際にインターフェイスを明示することがとても重要になってきます。言い換えると使い方がきちんと示されていることが最低ラインということです。ドキュメントは実際の処理と乖離しますし、各人がソースコードの処理を追わなければならないというのはチームでやっている意味がありません。 ところが JavaScript にはそういった仕組みが存在しません。どういった処理をするのかを表すための関数名は指定できますが、 JavaScript では関数を任意の名前の変数に代入できるので実はあまり役に立ちません。 といった状況にあった JavaScript ですが、昨今のツールの登場によって事情が変わってきました。 JavaScript でもインターフェイスを明示しながら開発するにはどうすればいいかを要素技術と一緒に書いていきます。 型チェック あくまでも JavaScrip
RubyでPageObjectsパターンを実装できる SitePrism のご紹介 - Qiita
この記事はSelenium/Appium Advent Calendar 2016の10日目の記事です。 はじめに freee株式会社でアプリエンジニアをしている @kompiro と申します。普段は selenium をガリガリ動かしているエンジニアではないのですが、SitePrism というgemを使って PageObjects パターンを実装してみたら、想像以上に捗ったのでご紹介します。 SitePrism の特徴 SitePrism とは PageObjectパターンをCapybaraを使って実装するためのDSL です。 例えば google.com のページオブジェクトを SitePrism を使って定義すると下記のようになります。 # Pageの定義 class Home < SitePrism::Page set_url 'http://google.com' element
E2Eテスト基盤開発を担当して - Qiita
freee Engineers Advent Calendar 2016 12月17日担当の @futoase です。 現在、E2Eテスト基盤構築の担当をしています。1 Capybara、SitePrism および Selenium に触れていく中で自分や弊社メンバーから得た知見について記載します。 4点の内容となります。 Capybara + SitePrism Selenium E2Eの目的 E2E基盤構築を担当してみて思ったこと Capybara + SitePrism 同僚の @kompiro が Capybara + SitePrism を使うことを提案、フレームワーク化を行ってくれたのでテストケース作成に利用しています。2 Selenium/Appium Advent Calendar 2016にてSitePrismを利用したPageObjectsパターンを使ったテスト作成につ
PhanでPHPのコーディング規約を自動チェックしよう - Qiita
再演: 「PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計」 + αという勉強会で、「assertぐらいでエバルんじゃねえ！」というふざけたタイトルで発表してきました。 資料はこちら。 PHP7では内部的にASTを作るようになりまして、それをPHP側から使えるようにするphp-astというC拡張があります。これを使って型推論つきの静的解析をするツールがPhanです。 Phanでは未定義変数や型に関する間違いを警告してくれるのですが、そういう明らかなバグの他にも自前のプラグインを作ってエラーをチェックすることができます。 スライドの趣旨としては、assertの話から入るものの、assertのことが主題ではなく、Phanを使ってコードの自動チェックを充実させようという内容です。 Phanプラグインの作り方 Phanプラグインの書き方は一応ドキュメントがあるのですが
質問は恥ではないし役に立つ - Qiita
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
テストの数を減らそう！プリキュアで学ぶPICT - Qiita
ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか？最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Googleが提唱するTestSizeとJava,MavenによるTestSizeの実現方法について - Qiita
「後付の型システム」の活用についてFlowtypeとReduxから考える - Qiita
https://qiita.com/itckw/items/ff079c7572d6a1acd349