Vue.jsで style scoped な単一ファイルコンポーネントのcssをオーバーライドする
https://medium.com/vuejs-tips/override-scoped-css-de4275119b87 単一ファイルコンポーネントを作る時、 style scoped として CSSの影響範囲をコンポーネント内に収めるわけですが、 コンポーネント外部から内部のスタイルを変更したい場合があります。 <template> <div class="box"> <div class="message"> <slot></slot> </div> </div> </template> <script> export default { name: 'box' } </script> <style scoped> .box { display: inline-block; } .box .message { background-color: orange; padding: 1
約3年かけてプログラマ向けニュース推薦アプリを作り直した話 - Qiita
概要 『もっとより良いニュースアプリはできないだろうか』 そう考えてMenthasというニュースアプリを開発し、プログラマ向けニュースキュレーションサービスを作ってみた話 という記事をQiitaに書き、自分の予想を超えた反響を受けてから約3年になります。 しばらく開発の更新は留まってしまいましたが、ニュース推薦に関しての探求が終わったわけではなく、むしろ見えてきた課題のために数多くの論文を読んだりプロトタイピングを繰り返していました。 そしてつい先日、これまで解けなかった問題に対してようやく答えを自分なりに導き出すことができたため、骨格となるアルゴリズムの刷新に始まり、ついで開発もインフラからサーバサイド、フロントエンド・デザインと、全面的なリニューアルを行うことに成功しました。 新しいMenthasは以下のリンクから使用することができます。 https://menthas.com 今回は
Vue.jsとNuxt.jsを使っていて、どっちのドキュメントを見ればいいんだ？ってなったときのために機能を整理する。
Vue.jsとNuxt.jsを使っていて、どっちのドキュメントを見ればいいんだ？ってなったときのために機能を整理する。 開発に慣れてきたら迷うことはないと思いますが、Vue.jsをさわるのが初めてでNuxt.jsを採用した場合、どっちのドキュメントを見ればよいかわからずに、さまよってしまう事があるかもしれません（自分がそうでした）。そんなときのための、長ったらしいメモです。 この記事を書いている時点では、Vue.jsが2.5、Nuxt.jsが1.2です。 ドキュメントの歩き方 まずはガイドで概要を把握して、細かいことが気になったらAPIをあたります。 Vue.jsでの開発がはじめてであれば、本格的に書き始める前に、スタイルガイドを見ておくと、手戻りが少なくなるかもしれません。 ガイド フレームワークの使い方がわかりやすく書かれています。 はじめにから順に読んでいって、大体こんなことができる
フリーランスエンジニアの単価を決める - Qiita
記事概要 書いた目的 フリーランスエンジニアの単価設定に「情報の非対称性」ある フリーランスは市場動向掴んで「売り手」になるべき エンジニア応援したい、優秀なエンジニアは年収伸ばせば良いし、キャリアミスマッチしてるエンジニアは再構築すれば良い 読者想定はフリーランスエンジニア、qiitaに多そうだから投稿 記事の内容 1. 自分のプロフィールと単価を公開 前職年収900万円で、フリーランス日額6.5万円〜10万円 40社ぐらい営業して、1/3は話が進む 2. この単価設定にした根拠を説明 前職基準、採用市場、派遣、フリーランス市場、英語圏 3. 終わりに 「こんな人材求められてるんじゃないかな」、「こうしたらキャリア積めるかも」を記載 正社員に戻って修行するなら、開発チームが強い（CTOが役員として存在）イケてるWeb企業で正社員キャリア積むことを目指すべき フリーランスのままでも「チーム
ReactとVueのどちらを選ぶか - Qiita
主に非Web系のバックエンド開発者(C/C++, Java, Python等を使用)がReactとVueをそれぞれ簡単に触れて、感じたメリット、思ったことなどをまとめています。 色々と書いてますが、どちらも完成度の高いライブラリ/フレームワークですね。 結論 JavaScript等にあまり深入りせずにWebアプリを簡単に書きたい、あるいは効率的に書くことが目的であればVueの方がお勧めです。しかし開発者としてスキルや設計などについて中長期的にレベルアップを図りたいのであれば、Reactから学ぶことをお勧めします。 何故かと言うと、ReactとVueにはそれぞれの利用者に対するスタンスが明確に異なり、Reactの方が利用者を開発者であることを想定/期待しているからです。 Reactは利用者が「開発者」であることを想定/期待します。 What, Whyを重視する 利用者を厳しめに教育する Vu
Electronアプリをリリースするまでにあった知見 - Qiita
はじめに こんにちは、@tsuwatchです。普段はRubyを書くのですが、仕事の幅も広がりつつあり、フロントエンドも本格的にやっていこうということで、 Kaizokuというニコニコ生放送のデスクトップアプリをリリースしました。 人生の大半の時間がニコ生に溶けているわけですが、かねてからコメントビューワを作ろうと思っていたので、この機会に作ってみました。 しかし、Mac版のコメントビューワにはHakumaiという大変素晴らしいコメントビューワが存在するので、少し違う方向を向いた生放送ビューワをかねたアプリにしました。 Hakumaiはコメントビューワとしては数少ないオープンソースなので、実装やコメントサーバの仕様など大変参考にさせて頂きました。この場をお借りして、お礼を申し上げます。 アプリの機能や今後についての紹介はまた別途ブログで書くと思います。 ご興味がありましたら、ぜひ使ってみてい
フロントエンド開発初心者がelectron-vueでアプリをつくってみた その２～実装編～
はじめに SC（非公式） Advent Calendar 2017 24日目！クリスマスイブですね♪ その１ は概念編でしたが、今回は実装編ということで、 ログインからのページ遷移→座席表表示→検索→検索結果表示まで実装してみたいと思います(｀･ω･´)！ electron-vueと銘打っておきながら、ほぼVue.jsのお話です。 開発時に躓いたところを中心に、参考資料をあげながらまとめています。 Main Process ひとまずはウィンドウが立ち上がればよいので、electron-vueインストール時に自動生成されたまま変更しません。 'use strict' import { app, BrowserWindow } from 'electron' if (process.env.NODE_ENV !== 'development') { global.__static = requ
imgタグの画像読み込みを監視する - Qiita
imgタグの画像読み込みを監視する この記事はjQueryの使用を前提に書いています。ご注意ください。 課題 JavaScriptでDOMのレイアウトを操作する場合、DOM内に画像があることで思わぬバグが発生することがあります。特にサイズ指定をする場合に上手くいかないことがよくあると思います。今回はこれを解決します 原因 「画像が読み込まれる前に処理を実行する」が原因です。 そのため、 サイズが取得できない サイズ０で操作している といった状況が発生します。 簡易な対応では問題がある 簡易な対応方法では、windowのloadがあります。 しかしこれでは以下のような問題を抱えています。 表示まで時間が掛かる JSエラーが起きると完了しない。 windowのload関数は、すべての要素が読み込まれてから実行されるため、要素が多いとかなり時間を要します。2番目はSNSボタンなどで発生しやすいの
Railsのcontrollerにおいて、メソッド外で初期化したインスタンス変数を参照すべきでない理由 - Qiita
Railsのcontrollerにおいて、メソッド外で初期化したインスタンス変数を参照すべきでない理由RubyRails 背景 Ruby on Rails を利用した中規模以上のプロジェクトにおいて、 Fat な controller を解消するために、処理を分割することはしばしば行われます。例えば、サブメソッドへの一部処理の切り出し, before_action, concern への処理の委譲が行われます。しかし、処理を分割する際に、メソッド外で初期化したインスタンス変数を参照してしまうような例を時々見かけます。 このような実装は、一見DRYでシンプルに見えてしまうかもしれませんが、実際には開発効率の低下につながったり、バグの原因になる可能性が高くなります。 この記事では、メソッド外で初期化されたインスタンス変数を参照することの危険性と、それを避けた方が良い理由を考察してみたいと思いま
書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだので大事なポイントを自分のためにまとめてみた - Qiita
書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだので大事なポイントを自分のためにまとめてみたGo初心者まとめアーキテクチャCleanArchitecture はじめに Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ。 なぜソースコードを綺麗に書くのかから始まり、オブジェクト指向、コンポーネントの原則、アーキテクチャと体系的にまとまっている良い内容だった。 この記事では、本書の内容の引用を踏まえながら自分の考えの振り返りをまとめたものである。 実際にGoで実装したりしたので、なにか間違いなどあれば指摘していただきたい。 クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた 対象読者 ・Clean Architecture 達人に学ぶソフトウェアの構造と設計を読むか迷ってる人 ・Clean Architec
【Swift, Firebase】究極の瞑想アプリを作った話 - Qiita
- json - github “SwiftyJSON/SwiftyJSON” - reactive - github “SwiftBond/Bond” - setting - github “nickoneill/PermissionScope” ~> 1.0 - ui - github “ninjaprox/NVActivityIndicatorView” - github “SVProgressHUD/SVProgressHUD” - github “airbnb/lottie-ios” - github “xmartlabs/Eureka” ~> 4.0 - github “danielgindi/Charts” ~> 3.0.5 - github “kaandedeoglu/KDCircularProgress” - github “ChiliLabs/CHIPageContro
RESTful API設計におけるHTTPステータスコードの指針 - Qiita
RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK：最も一般的 304 Not Modified：条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？（POSTのキャッシュは一般的ではない） 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict：作成しよ
書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた
本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2
Rails以外全くわからないマンがDjangoに触れてみて驚いたRailsとの違い - Qiita
はじめに Ruby on Railsといえば、言わずと知れたRuby製のWebフレームワークですよね。様々なスタートアップで採用されており、世界で最も人気のあるWebフレームワークの一つと言っても過言ではありません。私はこの一年、ほとんどこのRailsのみを使って開発をしてきました。 一方で、このRailsとよく対比されるのがPython製のWebフレームワーク、Djangoです。こちらも非常に人気があり、初心者向けにDjangoとRailsを比較したインターネット上の記事なども多く見受けられます。 こちらは自分には縁のないもの、と勝手に私は思ってきたのですが、先日から縁があって知人のDjangoプロジェクトをお手伝いしています。「RailsわかるならDjangoもわかるよ！」と言われて軽い気持ちで手伝い始めたのですが、触ってみると思った以上に違うところがたくさんありました。今回はその中の
Atomic Designってデザイナーには難しくない！？という話 - Qiita
Atomic Designってむずくないすか？ なんか、良さそうなのは分かるんですよ。 UI要素を最小単位まで分解して、それを共通化して再利用性を高めて工数減らしていこうぜ！ということなのは分かるんです。 Atomic Design を分かったつもりになる こちらはDeNAの記事で、単純に「Atomic Design」でググると最初に出てくる記事です。SEOが強め！（2018/07/30現在） こちらの記事、確かに詳細に書かれているんです。 2016年にこんな記事を書けるなんて、当時口を開けてアホ面で仕事をしていた自分なんかからしたらもう感服するしかないです。 英語の記事しかない中で、最先端なことを書けるDeNAはやっぱりすごいな私は何してんだよって話なんです。 ただ、この記事を、こんな優良な記事を読んだとしても、実際に作り始めると、、、 ButtonってIconも文字も入ってくるけど、こ
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です。 この記事の対象は「テストを書く技術がなく、テストを書く気がない」組織に所属する人です。 アジャイル開発において「テストコードは当然」なのか？という記事で（私の記事をきっかけとして）テストコードの「徹底」とか「カバレッジ100%」とかを批判し、トレードオフ
Vue.jsで開発を始める前に決めておきたい事 - Qiita
ここ１年ほど実務でVue.jsを利用してWebアプリケーションを開発しています。 今回はVue.jsを使ってチームあるいは個人で開発を始める上で予め考慮しておくと良さそうな事をいくつか書きたいと思います。 コンポーネントルール Vue.jsは単一ファイルコンポーネントによって、とてもシンプルな記述でコンポーネントを作る事ができます。しかし、開発者同士でコンポーネントの認識を揃えておかないと同じようなコンポーネントが作られてしまい、保守性を低下させる要因になってしまいます。 そのため、昨今ではAtomic Designなどの考え方をベースにコンポーネントを管理する方法が用いられています。Atomic Designを用いたコンポーネント設計方法については、以下の記事が参考になるかと思います。 Vue.js × Atomic Design - it's an endless world. いずれ
モバイルアプリアーキテクチャ勉強会 - Qiita
public class MainActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); Log.d(msg, "The onCreate() event"); } } つまり M-VC iOS も Android も View と Controller がまとめられてる M-VC なコードになる Model, ViewController という関係性 テストがかけない... だから設計談義が盛り上がる アーキテクチャを導入する目的 保守性の高いコード FatController にしない テストのかきやすい構成へ 考え
【iOSDC2017】MVC→MVP→MVVM→Fluxの実装の違いを比較してみる - Qiita
はじめに iOSDC2017にてMVC→MVP→MVVM→Fluxの実装の違いを比較してみるという内容で、Githubのユーザー検索のデモアプリをベースにした発表資料で登壇させていただきました。 登壇枠が15分だったため、ViewControllerを跨いだ（FavoriteViewController <-> RepositoryViewController）4つのデザインパターンの実装の違いにフォーカスした内容となっているので、画面遷移やテストの書き方などについても補足説明を書いていきます。 ※MVP、MVVM、Fluxでの補足説明という形で書いていきます。 登壇資料は下記になります。 本日のプレゼン資料、アップしました。https://t.co/TIecyULVp4#iosdc — marty-suzuki (@marty_suzuki) September 17, 2017 また登
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Vuexの構造を超簡単にnamespace(名前空間)分割する - Qiita
