  |
はてなキーワード: Bootstrapとは
htmlの中で
{{form}}とかやると受け取ったformを展開できて非常に便利なのだが
例えばbootstrapなどを使いたいときにclassの指定とかするのに困る時がある。特にテキストフィールドなど。
これに対しform.pyなどで定義した自作form内のコンストラクタでclass=form-controlを付与することで対応できるそうだ。
でもそれだと何のために見た目と中身を分けているの？html内の記述で対応できないと一貫性がなくない？
現にdjango-bootstrap-toolkitみたいなのがあってbootstrap4で使えるかはわからないけど
{{form | class-format}}みたいな記述ができるみたいだ。こういう方向性を目指すべきだと思うのに、何故フォーム作成のコンストラクタで対応しようとするのか。
はてなNGの代替品 for Firefox の Android 対応
はてなNGの代替品 Chrome1.0.3/Firefox1.0.1 を公開した
疲れた。
連休なので、はてなNGフィルターを作ったらクソ快適になった話
HaxeやBootstrapは使わず、JavaScript(+jQuery)とポップアップ用htmlを手書きしてます。
$5は払いました。
一部サイトの強制非表示をどうしても解除したければソースを直接修正して開発用パッケージとして読み込めば行けますよ。
難読化はしてないので5分とかからず外せるでしょう。アップデートは適用されなくなりますが。
Web制作において持論がある。CSSの設計云々で議論できるのはまともな営業が居てまともなクライアントをつかまえてきてまともに意見を言えるからだ、そうでなければCSSの設計云々は話にならない、お話にならない。
OOCSSにBEMにSMACCS、そんなもんできるかよ。クソみたいな、デザインを破壊する修正が大量に来て統一性もなにもあったもんじゃないし、セマンティック? 知るかくたばれ。アニメーションすらバラバラに指定されてっからAnimate.cssすら使えねえ。そもそも統一させてもらえないからクラスの意味がほとんどねえ、全部IDでも変わんねーよ。
頑張ったよ。SASSで綺麗に書こうとしたし、Smartyみてーなテンプレートエンジンが効率良いってのも分かってるよ。でもヘッダーすら変えろとか言われたらどこを共通化すればいいんだよ。
俺は確信した。Bootstrapの"mt-2"とか"display-inline-block"みたいにクラスを付けてってそれにスタイルを適用してくのが正解だって。ってかBootstrapのクラスばっかりでスタイル作ってる。だってクラス見るだけでスタイルが分かるし、共通化は一切されてねーからな。
あいつら、グラフィックデザインと同じだと考えてやがる、くたばれ。ポスターじゃねーんだよ。
俺はもう闇のWeb製作者になり客にはバキバキに嘘をつくようになった。SEOがだとかデバイスの保有率のデータだかなんかを持ち出して出来るだけ頑張らなくて良いサイトを作る。だって頑張ったってそれはカオスを作るだけの技術が上がるだけでコーディングの技術が上がる訳じゃ無いからな。
かと言って外注に出したらクソみたいに思いCSSフレームワーク使ったサイトが上がってくる、くたばれ。しかもグリッドシステムぐらいしか使ってねーじゃねーか、skeletonでも使っとけ、ふざけんな。
おかげで俺は毎日Web2.0的なデザインとレスポンシブ対応が混合した、パラレルワールドみたいなサイトを作ってる、スチームパンクだろ、お前営業やめろよ。単価安いんだよ。俺が営業行くから。元営業だからお前より喋れるから。
とにかくモジュール化だとかクラス命名手法だとか議論出来るお前らは幸運だ。全部の国がそれぞれ違う大陸にいるようなもんだ、クラスいらないからな。誰かWebpackであいつらの前頭葉をパッキングしてくれよ。
まず、自分はweb製作会社に勤めてる身なので、一通りの制作手順は知ってる。
そして、アダルトアフィリエイトサイトなるものを教えてもらった。
なんせ金にならん。（※webクリエイターは金など気にせずシコシコ勉強するのが大事）
といっても、お金はかけたくない。
できれば無料で。
そして、色々調べた結果、
まあ、無料なだけあって、色々縛りはつくんだよね。
最初はスクレイピングで、ほぼ自動化したサイト作ればいいんじゃね！
的なことを考えていたけど、FC2の無料サーバだと致命的なことに、DBやサーバサイド言語が使えない。
飛車角抜きで将棋しろとか、コンバイン使わずに田植えしろとか言われてるようなもんかな。
なので、フロントエンドの技術(html / css/ js)だけで、RSSとかの情報取得したりしてねー的なことをしないといけなくなった。
うーん、要はドラクエで言うなら、簡単な呪文は使えるけど、ほぼ素手でたたかえって言われてるようなもんかな。
とりあえず、サイトの体裁を整えるためにまずは、bootstrapのサンプルを改変してベースを作った。
bootstrap便利。http://getbootstrap.com/
あとは、幾つかのアフィリエイトのサイトに登録してパーツを配置。
動画も著作権やアダルト動画を載せる際の調査をして、一通りの知識を得る。
あとは、どんなサイトにするか。
ぱっと思いついたのは、普通のエロサイトよりもページ遷移を無くして、
どんどん動画を見やすいようにすれば、いろんなページから探し出す手間を省けるのではと思った。
なので、構成としては、クリックしてモーダルウィンドウの中で、動画が再生する形に統一。
動画の採取場所はDMMの無料サンプルとXVIDEOSでおｋ。
で、１ヶ月運用してみると、シングルページの弱点を身を持って体験した。
SEOにクソ弱すぎる。
どうしよう流行りのシングルページ（なんちゃって）にしたのに・・・どんどん検索順位が下る。
そこで起用したのがpushState。
jsでURLを書き換える技術。ただ書き換えるだけじゃなく、履歴そのものを作成してくれる。
これをすると、グーグルさんのクローラがシングルページのサイトでもうまいこと動いて順位があがった。
（若干iframeとの挙動で問題はあるが、ないよりまし。まあいける・・・。うん。）
てな感じです。
収益化はまだ全然できてないけど、仕事でサイト作るよりも自由だし、
Webエンジニアはだまって、アフィリエイトしてみるのも面白いかもね。
最近は収益どうこうより、自分が作ったサイトに人が訪問してくれるだけで嬉しくて、
↓まあ抜いていってくだせえ。
◎ START ↓ ● 既存Webサービスはありますか？-yes→● 既存のWebサービスのCSSをいじってスマホ対応しましょう。おわり ↓no ● そのスマホアプリが関係しそうな要素を次の中から選んでください。いくつありますか？ カメラ マイクロフォン 3Dレンダリング スピーカー バイブレーター 加速度センサ GPS BlueTooth NFC 内蔵DB 地図 動画 Push通知 -2つ以上→● ネイティブ一択です。端末ごとにプログラムを書くのは面倒ですが、それを明らかに上回るメリットがあります。おわり ↓1つ ● Webに置いておけば誰でも見ることができるコンテンツを、あえてApp Store、Google Playで配信する理由はありますか？-no→● お察しの通り、Bootstrapか何かを使って普通のWebサイトを作るのが良いと思います。あとでURL教えてね。おわり ↓yes ● そこまで言うなら、PWAが良いと思います。あとで追加機能が欲しいと言われたら、PWAはすぐに捨ててネイティブに移植すること。それができないならあなたの気力が尽きておわり
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
React.js界隈の人に聞きたい
http://anond.hatelabo.jp/20160521163144
最近某所で、React使うとjQueryは不要だ的なタイトルの記事を書いちゃた気がするので一応反応しときます。長文ごめんね。
えーととりあえず、あのタイトルは実際のところ省略しすぎであり、もちろん本来は「場合によってはjQueryは不要」「jQueryは要らないこともある」と長く書いた方が正確です（本文ではちゃんとReactが万能ではない説明をしてる）。でも多少釣りっぽいタイトルの方が読まれるようなので反省はしていない。
そもそも世の中にそんなにSPAがあるのか
世の中の絶対数は知りませんが、自分の脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、＜input type="hidden"＞とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。
というか、ちゃんと書かれたSPAは使っていてSPAであることにそもそも気づかないので、「SPAだから使いづらい」という主張はよく分かりません。GitHubやTwitterサイトがSPA的なことをしている故に使いづらいでしょうか。偶然タブを開いてたので調べたらそうだったから紹介しますが、例えばWebpackのドキュメントサイトは（Reactではないけど）SPAで、ブラウザでMarkdownをレンダリングしています（ http://webpack.github.io/docs/ )。サーバサイドで動くスクリプトもタスクもゼロ。個人的にはこういう使い方で十分嬉しいです。
何にせよReactのメリットが真に活きるのはある程度の規模以上だと思うので、小規模で導入してjQueryより短くならないことは普通にあります。自分中の閾値としてはJSコードが数百行超えるならもうReact使う。
JSXを使うことに抵抗ないんですか？
んー、要するに「別物であるDartやCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか？ 正直その主張を聞いたのは初めてです。歴史的にJSXとES6は完全に独立して発明されました。最近になってBabelが両方同時に扱えるようになりましたし、Babelはまさにそういう拡張性を重視しているツールです。それは「ああ便利になったね」というだけの話であり、なぜ「ES6とJSXは混ぜるな危険」となるのかよく分かりません。現にこれが最も標準的で人気の組み合わせです。
「JSXを使うことへの抵抗」ということなら、とにかく見た目にコレがキモいと感じる人が非常に多いのは事実です。現に、JSXより見た目がキモくないことを売りにしている仮想DOM実装が一定の人気を博していたりします。でもそういうライブラリは「キモさ」軽減のために結局新たな構文やら独自コンパイラやらを編み出して柔軟性を犠牲にしています。JSXは「関数呼び出しのシンタックスシュガーをJavaScriptに1個導入するだけで問題を概ね解決する」というシンプルかつ一番表現力の高い解決方法だと思います。仮想DOMの思想に逆らわない最も素直なやり方であり、将来長持ちする気がしています。
とはいえ所詮JSXはシンタックスシュガーなので、使いたくないなら使わず、本来の関数スタイルで仮想DOMを書いてReactを使ってもいいです。タイプ量が増えて若干見づらくなるだけなんで。
それと、JSXじゃなくてテンプレートでいいじゃん的に思っているようですが、テンプレートは仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います。
Reactはもう登場して3年経過して未だに勢いが増していますし、日常で困らないレベルのコンポーネント集も揃っています。React-Bootstrapはいいぞ、心が豊かになる。そろそろ採用してもアーリーアダプターとも言えんでしょう。むしろ真に先端を見るのが好きな人に言わせりゃ、2015年なんて「Reactが淡々と成熟していくのを見ているだけの、つまらない年だった」みたいな感じらしいですし。
Reactは現時点で既に3年に1回レベルのビッグウェーブであることは疑いようがなく、「これが10年に1回、つまりjQuery以来のビッグウェーブなのかどうか」については、そう信じている人と懐疑的な人がいる、という状況です。私はAngularもCoffeeScriptも「3年に1回」レベルに感じたのでスルーしましたが、Reactには「10年に1回」の方になりうる素質を感じています（個人の感想です）。将来もっと凄いものが出るとしたって、それは「ベターjQuery」ではなくて「ベターReact」でしょう。通常は「3年に1回」レベルでも試したり仕事に使ったりして構わないと思いますが、10年に1回の技術でなければ使わない主義の方は、あと2～3年待てばよいと思います。
保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います。
http://anond.hatelabo.jp/20160521163144
内容から誰が書いてるかわかるかもしれんけど、まぁスルーよろしく。
jQueryもそんなにガッツリ使ってるわけでもないし、Reactはまだリリース前の調査兼下地作りの段階だけど
正直言ってjQueryに戻るつもりは毛頭ないぐらいReact便利だと思ってる。
でもjQueryを捨て去れるかというとそれも無理だと思ってる。
その辺のことを適当に書いてみる。
社内サポート的なことやってて、サポートのテンプレート対応を省力化するために
Webでツール作って人が対応するコストを減らすために使ってる。
jQueryで一つツール作ってリリースしてそこそこ人的コスト削れたのはよかったと思ってる。
最大にして一番の理由がこれ。
そんなに大規模なアプリケーション作ってるわけでもないし、関係者も俺一人だけど正直DOMツリーを脳内でくみ上げるのに疲れた。
500行もいかないようなショボいコードでも脳内DOMツリーと格闘するのしんどい。
DOMツリー触るほうが楽ってみんなどの程度のコードでそんなこと言ってんの？
そんなスーパーハカー揃いなの？信じられないんだけど。
オリジナルのbootstrapはどうしても頭に入ってこなかったし、手を付ける気にもならなかったけど
React-Bootstrapはマジで楽だし、スッと理解できる。マジ最高。
Bootstrapってこっちを本筋にすべきじゃね？と割とマジで思ってる。
まだ触って3日も経ってないけど。
これはちゃんとしたWeb界隈の人は利点と思わないのかもしれないけど
一人でいろいろ賄わざるを得ない俺みたいな人間にとってはマジで楽。
ベースのHTMLにはベースのdiv一個載せとくだけで後は全部js。
レイアウトを大元のコンポーネントでReact-Bootstrapで組んで、あとは各コンポーネントを
個別に作っていけばいい。
HTML見て、CSS見て、JS見て、っていちいち記述方式の違うコードを見る必要がないのは
少なくとも俺にとっては一番楽。
やっぱまだReactはコンポーネントがそんなに揃ってないんだよね。
だからjQueryも使わざるを得ないけど、それも一つのコンポーネントに閉じ込められるから
管理が楽。
極力なくす方向で行くつもりだけど、今はまだ両方使ってる。
あの気持ち悪いコード考えた人はマジでいい意味でも悪い意味でも頭イカレてると思う。
気持ち悪くて仕方ない。いまだに大嫌い。
どんなに気持ち悪くても、結果が伴う以上使う。
5年後も自分がこの仕事やってるかどうかもわからんからそんなこと気にしたことない。
今ある仕事をなるべく早く簡潔に実行するために最適だと思ってるツールを使ってるだけ。
それがかつてはjQueryだったし、今も一部jQueryだし、大半がReactになろうとしてるだけ。
将来まだこの仕事やってて、もっと有用なツールがあればそっち使う。
俺みたいな一人前にすら届いてない奴の意見なんぞ必要ないだろうけど、
自分の今の考えを書いておくと後で見返せるかなと思って適当に書いてみた。
家でもアプリとかWebサービス作るのが趣味のプログラマーだけど、
作ったもののデザインが基本糞ダサくなるから本当モチベーション下がる
だってさ、どんだけ最新技術とか詰め込んだって時間つぎ込んで作ったって
アイディアが面白かったってデザインがダサい＝クオリティが低いってことじゃない
個人プログラマーが作ったサービスって機能性は負けず劣らずでも
「あ、これはデザイナーを雇う金のある法人が作ったサービスだ」
「あ、これはデザイナーを雇う金のない個人が作ったサービスだ」
こういう感覚って多分リテラシーがかなり低い人達でも割りと瞬時に感じ取ってると思う
最近はデザイン用のフレームワークなんてものまであるがそんなもの騙し騙し使ってもやっぱりダサいものはダサい
たまーに設計からコーディング・デザインまで全部一人でやってるっぽいのに
自分はゲームはあんまり作らないけど、ゲーム製作が趣味のプログラマーなんて
もっともっとこういうデザインできない現象に悩まされてるんじゃないか？って思う
アプリやWebサービスよりずっとクオリティとデザインが直結して評価されそうだし
ツクール程度ならともかく下手するとデザインできない＝作ることさえできない
みたいに技術はあってもスタートラインにすら立てないってことも結構あるんじゃないか？
