Angular で template内補完やエラーチェックできるようになったよ - Qiita
どうも @Quramy です。 さて、今日も今日とてAngular + エディタ関連ネタです。そろそろAngular 2というと怒られるらしいのでAngularと書きます。 先に成果を見てもらうのが手っ取り早いですね。コイツを見れ。 見ての通り、Angular Componentのテンプレート中でプロパティ名補完とエラーチェックを行えるようにしてみました。 上図はVimのキャプチャですが、もし、これを読んでる貴方がVisual Studio Codeユーザーであるならば、これ以降は全く読まなくてよいです。https://github.com/angular/vscode-ng-language-service にVSC用のpluginが転がっているので、こいつを入れればいいさ。 今日の想定読者は、Emacs, Vim, Sublime Text あたりを使ってAngularのコードを書いて
これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
go get しようとしたら SSL protocol error エラーが出るとき - Qiita
$ go get github.com/revel/revel # cd .; git clone https://gopkg.in/fsnotify.v1 /Users/xxxxxxx/go/src/gopkg.in/fsnotify.v1 Cloning into '/Users/xxxxxxx/go/src/gopkg.in/fsnotify.v1'... fatal: unable to access 'https://gopkg.in/fsnotify.v1/': Unknown SSL protocol error in connection to gopkg.in:-9838 package gopkg.in/fsnotify.v1: exit status 128
step by stepで始めるwebpack - Qiita
※webpack1系の記事です。 1→2への移行ガイドを見る限り破壊的な変更点はそんなにありませんが、preLoadersやpostLoadersがなくなっていたり、差が出ていますのでご注意ください。 https://webpack.js.org/guides/migrating/ webpackを手を動かしつつ学べる初学者向け資料を作成しました。 公式のチュートリアルもあるのですが、webpackが使用されているOSSのボイラープレートを見る限り、世の中の使われ方に沿ってないかも？と思い書きました。 これから始める人の手助けになれば幸いです。 また最終形のソースをupしてあるので詰まったら見てください。 webpackとは webpack で始めるイマドキのフロントエンド開発の説明が良かったので引用させていただきます。m(_ _)m webpack は WebApp に必要なリソースの依
FluxをjQueryに導入するためjquery.redux.jsを考えてみた - Qiita
FluxをjQueryベースのJavaSctiptプロジェクトに導入したいので FluxライブラリReduxと連携するためのjQueryプラグインを考えてみました。 Fluxの図を編集したものです。Reactを使わずjQueryのAPIで代替します 実装 ↓プラグインコード https://gist.github.com/nowri/bb00a12fe759ea055da7 ↓使い方サンプル // Action: var increaseAction = function() { return {type: 'increase'}; }; var actions = { increaseAction: increaseAction }; // Reducer: var counter = function(state, action) { var count; if(typeof stat
JavaScript初級者のためのコーディングガイド - Qiita
JavaScriptは大変難しい言語です。Rubyの難易度を2、Cの難易度を5、C++の難易度を8にすると、JavaScriptの難易度は12ぐらいあると思います。このコーディングガイドはそんなJavaScriptの深みに嵌まらないようにするためのJavaScriptの書き方を規定したものです。初級者1のための物ですので、わかってやっている人に好きにやってください。 このコーディングガイドは絶対に従わなければならないものではありません。私は一切強制はしませんし、初級者が従わなければならないという義務もありません。採用するしないはみなさんの自由です。 禁止編 JavaScriptには安易に使用してはいけない機能があります。下記の機能は、それぞれの機能を使っても良い、または、使うべきであるという理由を説明できない限り、使用してはいけません。 ==、!= ==と!=を使用してはいけません。代わり
Walts - Angular 2向けFluxライブラリを作った - Qiita
この度、Waltsというライブラリを開発した。ウォルツとも読めるが、ここはワルツと呼んでもらいたい。View -> Action -> Store、この三角の動きを三拍子に見立てて名付けたものだ。 crescware/walts 数々の検証や他のライブラリの知見を経て開発に着手したのが、Angular 2用を意識して設計したFluxライブラリ"Walts"である。他のライブラリの知見や昨今のFlux事情については前日の記事にて綴ってある。 これは2016年4月に開発を始めており、それまでに私が経験してきたフロントエンドの難点や当時の案件の問題点、反省点などを数多く活かしたものとなっている。Almin.jsとも開発時期が近いようだが、全くあずかり知らぬところで開発しており、結果的にはAlmin.js側が先出しになったのでそちらも参考にしている。 DDD, CQRS, Redux, RxJS,
業務でWebサービス開発をする際に気をつけたいこと（新卒向け） - Qiita
趣味でも業務でも日々Webサービスを開発しているzaruです。こんにちは。ついにアドベントカレンダーも最終日です。まだサンタとしての仕事が残っています。さて今回は仕事としてWebサービスを開発するときに気をつけたいポイントを紹介します。まぁ仕事に限った話じゃないですが…参考になれば幸いです。特に新卒プログラマあたりに読んでもらえればと思います😀 なお僕の業務上インフラ周りはAWSが多いです。 RASISという指標 RASISという指標があります。コンピュータシステムの評価指標5つの頭文字を取ったものです。 Reliability（信頼性） Availability（可用性） Serviceability（保守性） Integrity（保全性） Security（機密性） 今回はこの5つの指標に沿ってポイントを紹介していきます。RASIS自体については色々なところで解説されていると思うので
QiitaのサイトにBEMを勝手に取り入れてみた - Qiita
BEM Advent Calendar 2013 1よ…13日目の記事です。 BEM Advent Calendar 2013が14日時点で18日の記事がアップされていたり、逆に13日の記事が14日にアップされたりと時空が歪んていますが、気にしないことにします。 この記事では、BEMを取り入れたマークアップがどんなものになるのか、Qiitaのホーム画面(ログイン後)を元に考えていきます。 なお、BEM自体についての説明は、BEM Advent Calendarの各記事やBEMという命名規則とSass 3.3の新しい記法 - アインシュタインの電話番号、CodeGridのBEMによるフロントエンドの設計 - 基本概念とルールを見ていただけるようお願いします。 これから載せるソースのガイドライン BlockとElementの区切りにはアンダースコア2個(__)を使用 block__elemen
現在のプロジェクトで使用している CSS 設計ルール (BEM ベース) のまとめ - Qiita
この記事は、現在僕が携わっているひだまりプロジェクト (仮称) で使用している CSS 設計ルールについてまとめたものです。 ベースとなる CSS 設計 BEM (MindBEMding) BEM 自体についての説明は省略します。 一部 SMACSS を参考にした独自ルールを取り入れています。詳しくは後述します。 (1) Element をネストしない BEM を使用する際の大原則として block__element という対応関係を厳守します。 NG category__item__name は block__element1__element2 と Element がネストしています。 <head> <style> .category-list {} .category-list__item {} .category-list__item__name {} </style> </hea
npmでTypeScriptの型定義を管理できるtypesパッケージについて - Qiita
どうも、らこです。 Angular 2の開発リポジトリでは型定義ファイルの依存解決に関して、最初はtsdだったのが途中でtypingsに移り、そして最近またtsdに回帰していたのですが、ついにtsdすらも使わず、npmだけですべてを解決するようになってました。 いったいどうやって？というのが今回のお話で、結論から言うと @types スコープから公開されているパッケージがdevDependenciesとして依存されるようになっていました。 @types typesという名前のユーザーで、明らかにbotだけど中身はMicrosoftの人らしい。(メールアドレスから) どのパッケージもだいたい 2016/5/17 に最初のpublishがされているらしく、最近始まった取り組みのようです。 現在1700超のパッケージが公開されてますが、すべて型定義ファイルのパッケージです。型定義は https:
FLOCSSを使ってCSSファイルを20,000行から9,000行にした話 - Qiita
入社して僕が最初にアサインされたのがこのプロジェクト。 サービスをスタートさせたのは今年の２月。最初は外注でとりあえずサービスを作ることに集中していたらしい... その結果、どのスタイルがどこに作用するか全く分からないCSSの魔境でした。 これでは簡単なページを追加するにも一苦労。 そこで、20,000行あるCSSファイルのリファクタリングに踏み切りました。 当時の問題 スタートアップのサービスなのでもっと機能を追加したり、変更したりしたいと言う要望は日に日に大きくなっていました。 一方で、実際に機能を作ったとしてもそれを view に反映させるのも日に日に苦しくなっていました。 僕たちを苦しめていた理由は以下の通りです。 どこにスタイルが作用しているか分からないので、CSSを安易に変更ができない。 新しい部品を付け足す時にCSSの影響範囲を考慮しなくてはならず、プロダクトのUI変更が困難
QiitaのCSS構成2016 - Qiita
Qiitaを開発しているIncrementsで、フロントエンドをやっていってる @morishitter です。入社して4ヶ月が経ち、会社にも少しずつ慣れてきました。 CSS Advent Calendar 2016 の1日目の記事として、Qiita及びQiita:TeamでのCSSの構成について書きます。 脱Sprockets Qiita / Qiita:Teamでは、サーバーサイドのアプリケーションフレームワークとしてRuby on Railsを採用しています。そのため、これまでは Sprockets というRailsにbundleされているassetビルドツールを使ってSassをCSSにコンパイルしていました。しかし今では、全てのCSS, JSのビルドをNode.jsで行っています。 CSSでの移行手順はざっと以下の通りです。 まず、Sprocketsで使われているRuby製のSas
知っておきたいCSSの呪縛と希望 - Qiita
CSSを扱いし者たちに課せられた永遠の呪縛。 「CSS簡単でしょ」と思ってる人のコードが混じる恐ろしさ。。。 2016年、全てのCSSの戦友たちに言っておきたいことがある。 今回、それらを３つのポイントに分けてお届けします。 この記事は CSS Advent Calendar 2016 の10日目の記事です。 １．本当に怖いぞ - グローバルCSS 時は200X かつてCSSは様々なファイルに分かれておりました。 Common.css、Layout.css、Top.css、Info.css、Shop.css・・・ ページやモジュールごとにcssを分割し、必要に応じて読み込んでいた時代です。 この時代はCSSがいくらユルユルな仕様とはいえ、まだ平和でした。 つまり、読み込んだCSSファイル同士の関係さえ知っていればよいのでした。 201X 前期 (2010〜2013年ぐらい) CSSを1ファ
今年お世話になったCSSまとめ - Qiita
今年もあと3週間弱で終わりますね。 ということで、今年お世話になったCSSをざっとまとめてみたいと思います。 （最近同一ページ内で h1 タグは1つとかそうじゃないとか盛り上がってますが、この記事では何個も h1 使いますのであしからず） 間隔の空いたボーダー これには本当にお世話になりました。 普通に border: 1px dotted #000; みたいに実装すると、間隔は調整できないので、 background-image のグラデーションの機能を使ってボーダーを実装しよう、というやつです。 以下の例では「線幅1px、ドットの大きさ1px、間隔2px、横向きの破線」を実装しています。 注意点は、 background-image なので1つの要素に複数指定できない点です。 DEMO .hoge { background-image: linear-gradient(to right
サーバーサイドレンダリング不要論 - Qiita
サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け
恥かどうかはともかく、そもそも逃げられない障害対応のお話 - Qiita
システムエンジニア Advent Calendar 2016の20日目の記事だよ！ 昨日は@sh-ogawaさんの「SIerが実践する分散開発とバージョンコントロール」でした！！ システム障害のお話 は〜い、こんにちは！いよいよクリスマス間近ですね！ この時期になると、キャッキャウフフの予定も盛りだくさんだと思います！1 そんな大事な日に限って起こるのがあれです。 そう、みなさんもよくご経験されているだろう、システム障害です2。 システム障害 それはツラく長く険しい道のりを告げるゴングです。 今回は、その障害対応のお話をしたいと思います。 この記事のアジェンダはだいたいこんな感じです。 報告する はい、システム障害が起きました〜。 ｷﾀ━━━(ﾟ∀ﾟ)━━━!! 「マジでか…(´；ω；｀)ﾌﾞﾜｯ」 「なんで今日なんだよ〜( ；∀；)」 障害発生時の想いは人それぞれだと思いますが、まず最初
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/mesaka/items/8cf67d6439acac84411b
たった3行で実現できるCSSの上下中央揃え（Flexbox） - Qiita
