サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
qiita.com/arowM
ウェブアプリケーション開発における、現代的なCSSの基礎技術についてまとめました。 ちまたには「CSSとは何か」を学ぶ教材はたくさんあっても、「CSSをどうやってうまく使うか」についてはあまり詳しく触れられません。 仕様をたくさん記憶したところで、いつになっても開発力はあがらないのです。 本記事は「CSSをうまく使う技術」に焦点をあてて、実際に現代的なウェブアプリケーションに求められるレベルのCSSを書くための知識を紹介します。 特に プログラミング経験はあるもののウェブフロントエンドの経験が浅い方 初級レベルのCSSはある程度理解したものの、次にどうしたらいいかわからない方 にお勧めです。 プロローグ CSSの書き方は一通りではありません。 好きな書き方を自由に選ぶことができます。 これは一見すると良いことですが、裏を返すと最適ではない書き方がたくさんあるということです。 この場において
iOS safariの暴虐 iOS safariでは、スクロールできる要素に対してスクロールバーを表示しないという正気を疑う挙動をします。 現代は端末幅にあわせてコンテンツの幅を柔軟に調整するのが一般的需要ですから、画面幅によっては運悪くちょうどキリのいいところで文章が切れてしまうことは十分にありえます。そんな場合、ユーザーはその要素がスクロール可能だとはまるで気づきません。 もちろん、iOSを使っている人間はそういう不自由さを受け入れる覚悟があるからApple製品を使っているのです。愛の前では使いにくいことなんて何の障害にもなりません。 しかしサービス運営者としては困りものです。Appleなんか好きでもなんでもなくても、そういう暴虐の限りを尽くした挙動にも対応できなければ「使いにくい」っつって文句言われたり、コンバージョン率が落ちたり、ビジネス的な損失につながるのです。無視したくても無視
はじめに 去年の9月にこれまで4年ほど経営していた会社を解散しました。 「会社をつぶす」と聞くと、なんだか良くないことに聞こえますが、実はこの解散は前向きな理由で決断したものです。 解散理由が珍しいだけでなく、会社を作った経緯も、経営方針や採用技術についても、なかなかほかでは見られないものだったため、興味を持ってくださる方も多く、記事にして残すことにしました。 これから事業を起こそうとされる方、なかなか自分にあった活躍のしかたが見つからない方、世の中のあり方に思うところがある方にとって、多少でもお役に立てるものになれば幸いです。 いまは何をしているのか 法人をたたんだ現在は「UXハッカー」として生きています。 これは、UX = User eXperience (ユーザーの体験) の概念を独自に拡張し、世の中のあらゆるUXを改善するお仕事です。 UXといえば、最近「UXデザイナー」という職種
GUIのアプリケーションにおいて、ユーザーが入力した内容を検証する「フォームバリデーション」は必須の技術です。 しかし、静的型付けの恩恵を受けるために Flow, TypeScript, Elm, PureScript などをつかってフロントエンドコードを書くようになると、実はフォームバリデーションだけでは足りなくなってきます。1 この記事ではフォームバリデーションを包括した新しい概念である フォームデコーディング を紹介し、Elmでフォームデコーディングを実践するために開発した elm-form-decoder を使った実例をお見せします。 軽く調べた限りではフォームの入力検証について同等の概念を実現するライブラリなどは見当たりませんでしたが、もし似たライブラリなどをご存じの方がいらっしゃればご指摘いただけると幸いです。2 サンプルアプリ まずは現実にありそうな簡単なアプリケーションを題
URLをあらわす文字列であるとか、0以上であることが要求される整数であるとか、値が何らかの制約を満たすことを要求される場面は多くあります。 たとえば、男女2頭のヤギさんの角の本数を引数にとって、その2頭のヤギさんが愛し合って交尾して子どもを作っても問題ないかを判断する関数を定義します。 それぞれの角の数を引数にとって Bool型を返す自然な設計ですね? でも、ちょっとまってください! 有角のヤギさんは2本しか角を持っていません。 そのため、ヤギさんのとりうる角の数は以下のいずれかしかありえないはずです。 0本: 生まれつき無角のヤギさんか、有角の仔ヤギちゃんの角芽を焼きごてで焼いた(断末魔のような悲鳴がする) 1本: 有角の仔ヤギちゃんの角芽を焼いたけど不十分で1つだけ残った(断末魔の悲鳴が無駄になった😱) 2本: 生まれつき有角 3本以上: 染色体に異常があるので、ここではヤギとは見な
Haskell を用いたアプリケーション開発は 「新しく作るのには時間がかかってしまうが、その代わり強い静的型のおかげで保守性が高い」 と言われることがよくあります。 もちろん「いや、新しく作る際にもむしろ型のおかげですばやく作れる」などの反論もありますが、こういったトレードオフがあることもまた事実です。 さらに、Haskellの闇の力に飲まれてしまった方が書く厨ニ病コードは、本人すらも1週間後には意味がわからなくなって保守性すら低くなる怖さも秘めています。 今回ご紹介する Tonatona は、Haskellを用いたアプリケーション開発にありがちなこういった問題を解決して、今までの常識を覆す「統合的アプリケーションフレームワーク」です。 公式リポジトリ 最新の内容はTonatonaのリポジトリにあります。 トナカイのコスプレをしたさくらちゃんが目印です。 どんな人のためのフレームワークか
高品質なウェブフロントエンドを作るための言語 Elm の有用性が徐々に広まり、今年も採用事例が増えました。 利用者数が増えることは良いことではありますが、一方で悪気なく誤解を招く情報が生まれてしまう機会も増えてきます。 そこで、本記事はこれからElmをはじめる人やはじめて間もない人1が遠回りしないで Elm をモノにできるように、Elm を学ぶ上で落とし穴となる注意事項とその回避方法をまとめます。 なお、本記事で対象にするのは「実際に Elm を使って実用的なアプリケーションを作りたい」と考えている方です。 Elm をマウンティングのために使いたいマウンティングゴリラの方や、「プログラミング言語全部完全マスターした」と言うためにハローワールドやTODOアプリだけ書いて満足したい方は、別にそういう生き方も否定はしませんが本記事の対象外です。 そういう手っ取り早く形あるものを作ること自体に最大
Elm0.19になって、Elm0.18時代の elm-tools/parser も elm/parserとして新しく生まれ変わりました。 基本文法は Elm0.18時代 とほぼ同じなので、去年@jinjorさんが書いた Elm0.18の elm-tools/parser に関する記事の「基本文法」までを読めば理解できますが、Elm0.19から新たに加わった変更がいくつかあります。 そんな変更の1つ "backtrackable" は、elm/parser からリンクが貼られているドキュメントに説明がありますが、あまり親切とは言えません。 そこでこの記事ではより詳しく「そもそも backtrackable とはなにか」「どうやったらうまく使えるか」などをまとめました。 backtrackable とは ざっくり説明すると「ひとかたまりのParse処理において、途中でParse処理が失敗した際
のように自動的に書き換えてしまうのです。 もちろんCSSファイルのクラス名を書き換えるだけでは本来の text クラスを持つHTML要素にスタイルが適用されなくなってしまいますから、書き換えたクラス名の対応関係を JSON オブジェクトとして以下のように出力します。 HTML側がこの JSON オブジェクトを使って適切なクラス名を各要素に付与するようにすることで、無事に CSS で定義したスタイルがその要素に適用されます。 このようなクラス名の衝突をなくす工夫によって、アトミックデザインなどに使える再利用可能な CSS の記述が可能になります。 関連手法との比較 「CSS modules を使いたいから Elm で CSS modules を使えるようにした」みたいなのは無能な人がやることです。 いったん落ち着いて「本当に Elm で CSS modules を使う新しい手法を考える必要が
これは、UXデザイナーではない人がUXデザインを効率よく身につけるための方法論です。 私自身も本職はUXデザイナーではなく、ふだんはヤギと遊んだり新しい会社組織の実験をしたりプログラムを書いたりしています。 しかし、ヤギの飼育や経理、組織運営、マネジメント、営業、プログラミングのどれも、広い視野で見ればユーザー(=ヤギ、組織の構成員、マネジメントの対象、取引相手、他のプログラマ)の体験を改善する仕事です。 そのためUXデザイナーではありませんが、これらの「UXハッカー」と呼ぶべき多くの分野から得られた知見を用いて、UXデザイナーではない人間が理想のUXデザインを実現するための近道をご紹介できます。 なんだか小難しい用語を並べ立てることもしません。 小難しい用語を覚えても、わかった気になれるだけで、実際にUX設計をできるようにはならないからです。 ただし、これはあくまでもUXデザインを最低限
型って「どういうことをしてほしいか」っていう 要件 の役割を持ってて、 一方で実装って「どうやってその要件を実現するか」っていう 具体的な手順 の役割を持ってますよね。 ところで仕事ができる人って、「こういうことやりたいな〜って思ってるんだけど〜」って伝えると、 「あ、それなら具体的にこういうやり方をすると良さそうですね〜」って自分で考えて提案して実行してくれてめちゃくちゃ助かるじゃないですか。 そしたら、プログラムの世界でも同じで、要件 (型) だけ書いたら 具体的な手順 (実装) を自動で導出してくれる未来が来たら嬉しい感じがしませんか? ざんね〜ん! 未来ではなくそれは現代のお話でした〜! 1 type MyApi = "books" :> Get '[JSON] [Book] -- GET /books :<|> "books" :> ReqBody Book :> Post '[
Elm でどのように見た目をあつかうかについて僕がいま考えていることをまとめました。 結論として「BootStrap みたいな方針でCSSを書いて使えばいいよ」という単純な話を、 だらだら歴史的経緯とかどうでもいい話をしながら書きました。 従来の主張 まず、「見た目をあらわすクラス名を使うべきではない」と言われてきた背景をおさらいしたいと思います。 ここで言う「見た目をあらわすクラス名」とは、BootStrapのような方式のCSSフレームワークで採用している HTMLのクラス名に col-sm-8 や pull-right のような見た目に関わる名前のクラスを入れる方針のことを意図しています。 従来は HTML/JS/CSS の役割を次のように分け HTMLがページの構造のみを記述し JSが挙動のみをあつかい CSSが見た目をどう見せるかを全て制御する こうすることで、見た目の変更をしたい
はじめに 高品質なWebフロントエンド開発を可能にするためのプログラミング言語Elm。その長所を上げればキリがありません。 強い型制約によって実行時エラーをほぼゼロにできること リリースごとに言語機能が減るというどこまでも考えつくされたシンプルな設計 それでいて実用的なアプリケーション開発にとことん貪欲な機能たち まともなパッケージマネージャー テストしやすさ ...... 一方で、そういった強力な武器たちの切れ味を保つために他の言語とは異なる事情を抱えています。 本記事では、その特有な性質がゆえに誤解されてしまうことも多い Elm というプログラミング言語について、誤解を解きながら、唯一無二の魅力をお伝えしていきます。 この記事を書いた当時は Elm 0.18 の時代でしたが、Elm 0.19 が出た今でも変わらない内容です。 Elm の根幹部分について言及した記事なので、今後 Elm
はじめに 僕の本業は酪農で、ヤギのさくらちゃんをお世話するのが仕事ですが、それだけでは食っていけないのが世の中の悲しさなので、副業でフリーランスのITコンサル(兼プログラマ)や株式会社UZUZっていう会社のひきこもり系最高技術責任者としてHaskellやElmを業務で使っています。 あと、個人的な趣味で株式会社ARoWっていう社員数2名のちっちゃいWeb系の会社を実験的に経営していて、そこでもメインにHaskellを使っています。 Haskellを実際に小規模な会社やフリーランスで使っている人って、実は世の中にほとんどいないみたいです。 そこで、実際のところ「Haskellって資金力のない会社や個人が業務で使えるのん?」っていう疑問に対して率直にお答えします。 日本Haskell界の現状 まず、Haskell界隈の日本における現状についてお話します。 知ってる方も多いと思いますが、日本でH
問題提起 近年、フロントエンドを Elm1 や React.js などで実現することが多くなり、Webサーバに求められる役割は、JSON形式のAPIを提供するだけでよい例も増えてきました。 しかし、規模によってはHTMLにサーバサイドで変数を埋め込んでそのまま表示したい案件も多く存在します。 JSON形式で良ければaesonなどの恩恵にあずかれば良いのですが、Haskellで書かれたWebサーバで、バックエンド側の変数を埋め込んだHTMLレスポンスを返すにはどうしたらよいでしょうか? Yesodの解決策と課題 HaskellのWebフレームワークとして歴史のあるYesodでは、Shakespeareを推奨しています。 Shakespeareは、Haskellっぽいインデントベースの文法を強制されるというデメリットがありますが、Template Haskellによってコンパイル時にテンプレー
(筆者は今では積極的にはこの手法を使っていません。詳しくは追記をご覧ください。) elm-cssライブラリのCSS生成機能とelm-css-webpack-loaderを用いることで、CSS in Elm のさまざまな恩恵にあずかれます。 はじめに なぜ CSS in Elm が必要か CSS in JS という言葉が、React界隈で使われるようになっていくらか経ちました。 CSS in JS は、本来 CSS で記述するスタイルを JavaScript で書いてしまうことで、名前空間やネスト構造が使えない不便なCSSから解放されることを目的にしています。 Elm で CSS in JS (Elm) を採用することで、従来のCSSによるスタイルにおける以下の問題を解決できます。 a. スタイルの記述が Elm コンポーネントとは別のファイルになって、配布しづらい b. CSS に名前空間
はじめに @ruiccさんのスペースリーク、その傾向と対策のコメント欄において、@maoeさんが「最近のbaseではfoldlの実装にfoldrを使っている」という内容のコメントをされていました。 そのリンク先では、次のような形でfoldlを定義しています。 foldl :: forall a b. (b -> a -> b) -> b -> [a] -> b foldl k z0 xs = foldr (\(v::a) (fn::b->b) (z::b) -> fn (k z v)) (id :: b -> b) xs z0 (;・∀・) (;・∀・) (;・∀・) (;・∀・) (´・ω・`) なにを言っているのかわけがわからないですね! ということで、スペースリーク自体とは多少離れてしまうかもしれませんが、この記事ではなぜこれがfoldlになるのかを少しずつ解き明かしていきます。 き
qiita.com
手続き型に慣れた人にもやさしい、こわくないHaskell入門記事です。 「なぜHaskellを学ぶと良いか」も参考にしていただければ幸いです。 まえがき Haskellと聞いて、何を思い浮かべますか? モナド 関数型 遅延評価 第4世代Intel Coreプロセッサ アライグマ いろいろ思い浮かべるかもしれませんが、Haskellがすばらしいのはモナドを利用しているからでも、遅延評価型の純粋関数型言語だからでもありません。 いろいろな「Haskellらしさ」が集まって、その結果Haskellにしかないすばらしい魅力を提供してくれます。 それは、決していままでのパラダイムと対立するものではなく、 手続き型 構造化プログラミング オブジェクト指向 のようなこれまでの便利な道具をうまく抽象化しながら統合して作り上げられたものです。 PHP javascript C++ Java などにあなたが費
このページを最初にブックマークしてみませんか?
『@arowMのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く