  |
はてなキーワード: Bootstrapとは
まじな話をすると、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サービスよりずっとクオリティとデザインが直結して評価されそうだし
ツクール程度ならともかく下手するとデザインできない＝作ることさえできない
みたいに技術はあってもスタートラインにすら立てないってことも結構あるんじゃないか？
手持ちのプログラムをちょっと手を加えれば作れそうだったので作ってみた（総工数0.5MH)。最下位２つが404になってたおかげでちょっと変なことになってるけど、だいたいこんなもんかな。いわゆるホッテントリーに上がる記事を大雑把に分けると、
に分かれる（勿論ミックスもあるけど）。諸君が『くだらねー』と思っている、エクセルだの英語だの簿記だのは後者だな。ただ、はてブはSNSとして機能している側面もあるけど、SBMが本来の目的である以上、インフォメーション系の記事も当然上位に上がってくる。まあ、ブコメが盛り上がっている何か？を表示出来るようにしたいんだったら、日曜プログラミングでちょろっと書けば？と思う今日このごろ。
ブログに書くほどの話じゃないので、スペースお借りしますm(_ _)m
PHPでHTMLをコーディングしていて、とあるフォームのあるページからさっぱりPOSTで送信されない。formのmethodをGETに変えてみてもだめ。
print_r($_REQUEST) としても、 Array() と表示されるだけで中身が空っぽ。
bootstrapを使っていたのでそれ絡みかなとか、いろいろ悩んでしまった。結局inputタグにname属性の指定を忘れていたからだった。id属性だけは指定していたんだよね。ありゃま...
調べている途中で、IEのあるバージョンでは、form中にinputタグが1個しかないと、その内容がPOSTされないらしい。とんでもないなぁ...
かつて好きだった人の写真や好きな芸能人の写真から顔が最も似ているAV女優を検索するサービス。
既に好きなAV女優から新たなAV女優を発掘するという利用もできます。
僕はAV女優を顔重視で選ぶのですが、いろんなエロ動画サイトを見ていると、有名ではないが、自分の好みな顔のAV女優を見付けることがよくあります。
既存のエロ動画サイトはテキストで検索することは可能ですが、もしかしたら、まだ自分の知らない自分好みなAV女優がたくさん存在するかもしれないと
もし顔で検索できれば自分のAVライフももっと楽しくなるだろうと一念発起して開発しました（開発期間は半年くらい）。
| レンタルサーバー | GMOクラウド Public |
|---|---|
| WEB | Apache |
| DB | MySQL |
| プログラミング言語 | PHP |
| フレームワーク | Cakephp |
| UI | Bootstrap |
| 顔認識 | Face++ |
簡単に仕組みを説明すると、
①DMMのサイトをスクレイピングしてAV女優の基本情報（名前やスリーサイズなど）を登録
②DMMのAPIを利用して、それぞれの女優の作品を取得して、パッケージ写真中の顔面積を測り、最も面積が大きいパッケージ写真を登録
③ユーザーがアップロードした画像からFace++のAPIを利用することで顔検索して、最も似ているAV女優を8人表示
今はまだ、顔認識を他のサービスに頼っているので、いずれ内製化して全て自分で開発したいと考えています。
また、今は静止画でとどまっているので、動画に範囲を拡げて、画像をアップロードすると、
これです。
よく「エロサイトを作ってみた」記事でバズったりしていたので憧れていました。
・20代後半
・言語 → Ruby, HTML, CSS, java script
・デザインテンプレート → Bootstrap（Bootswatch）
さて、仕事がエンジニアということもあり、技術的に苦労したわけでも、勉強に時間がかかったということでもありませんので、
今どきのエロサイトを作るために、効率よく作れるポイントを書いていきたいと思います。
http://apiactress.appspot.com/
このAPIで、簡単にあいうえお順に8000人のAV女優の名前、顔写真といったデータを取得することができます。コレを活用して、収集した動画データのタイトルとマッチングさせて、「◯◯の出演する動画」といったデータを作ることが出来ました。
大手のエロ動画のアンテナサイトなどでは、数百サイトのクローリングをしています。しかし、1件1件、RSSリンクを調べていては日がくれてしまいます。
ある大手のエロ動画サイトが巡回先をリストにして表示していてくれましたので、これを整形して、サイト名、URLのリストを作成しました。そして、この
URLからRSSリンクを抽出するプログラムを書きました。それにより、一瞬で数百サイトのRSSリンクのリストを手に入れることができました。
人妻、熟女、ギャルといった重要なキーワードで検索できることも重要です。そこで、ここでも大手サイトのトップページに表示されていた50個ほどのタグを
重要タグとして位置づけ、タイトルとマッチングをさせました。こうすることで、巨乳の動画、貧乳の動画などが探しやすくなりました。
また、URLからmeta keywordsを取得して、それを単語に分解してのタグ付けも実施しています。
Bootstrapが流行りましたが、そのままでは、流石にダサいということで、https://bootswatch.com/ のデザインテンプレートを使用しました。
こういった流れで約5日で、
といった主要な機能を備えたエロ動画を立ち上げること出来ました！
まだアクセスが自分しかいません。。。是非、皆様ご利用下さいm(_ _)m
今年で社会人２年目です。
どうやったら、日々新しい知識や技術を学ぼうという姿勢が持続すると思いますか。
小さい会社でWEB担当が当方一人で、WEB製作のこと以外でも業務はあり、兼任で色々やっている感じです。
全部の時間をWEB製作には使えないので、主要部分のコーディングを外部に委託するなどして、
なんとか日々の業務をこなしています。
DTPデザイナーとして入社して、WEBデザインもこれから学んでいきますという時に
直属の上司（web担当）が辞め、初心者同然の自分が、小さな会社のweb担当として、
自社のHPの製作や他社のHPの製作・管理などを行っている状態です。
デザインしてもコーディングしても、毎回これでいいのかな、正しいのかなと思うことばかりです。
html,
css（animationとか、あいまいな部分も多々あります）,
eccube(全体のざっくりとしたいじり方、更新、ページの詳細編集)
×できないこと、これから学ばなきゃいけないこと
PHP、レシポンシブデザイン（ec-cube/wpに対応させるように）、bootstrap等、
WEBの担当者が身につけるべき技術・知識を、恥ずかしながらまだもっていません。
くらいです。見ての通り、知らないことや、できても浅い知識、ばかりです。
もうどこから手をつければよいのでしょう。WEB製作者として一人前になりたいのに、
現実の自分が追いつきません。周りの社員の方々はWEBについて疎いので、
その若さですごいねといわれますが、そのたびに心が痛んで仕方ありません。
もっと技術も知識も積むには、ひとつずつこなして毎日毎日勉強するしかないんですよね？
どれからやっていけばいいんですか？どうやって身に着けていけばいいんですか？時間の作り方は？
モチベーションの保ち方は？
Twitter Bootstrapの使い方を覚えるのを兼ねて、無駄に持っている技術を使ってエロサイト作ってみた。
検索、タグ検索等々まだまだありきたりなエロサイトの構成です。
ngx_pagespeedでCSS圧縮したり画像を最適化してくれたりdefer_javascriptしたりと、
ページの表示速度を優先したつもり。
Twitter BootstrapでレスポンシブWebデザイン。
裏側で動画のタイトル入力したり、掲載非掲載を操作できるCMSも作って
更新してもキャッシュ残りで残念な感じにならないように、キャッシュパージ機構も作った。
ついでにpubsubhubbubへPublishも作ったけどいまいちうまく行っているかわからん。
人間が産まれてから初めて感じる快感は、排泄によるものらしい。
リリースしてから1週間ほどだけどGoogleのインデックスもイマイチ。
100/日ぐらい。
こんにちは。2年前に『はてブ1000users超え記事アンテナ(´・ω・)』というWEBサービスを作って記事を書いたものです。
当時はWEB業界で働くことを目標にしていましたが、いろいろあって今はまったく関係ない業界の会社でお世話になっています。
※カーちゃんには温泉じゃないけど一応孝行出来ました。
2年前に応援してくださった方々、ありがとうございました！
・サイト：『はてブ1000users超え記事アンテナ(´・ω・)』
http://hatebu-1000users-over.com/
おかげさまで少し時間が空くようになったので久々になにかWEBサービス作ってみたいなあと思って今回新しくWEBサービスを作ることにしました。
以前今回ははてなユーザーに絞って作ったサービスでしたので、今回は反対に万人受けするものを目指して作ってみましたので、ひっそりとご報告したく思います。
といっても相変わらずif文を書くのがやっとのPHP初心者なので大したことは出来ないですが。。。
『@漢字の読み方（β）』
・このサイトについて
タイトルのまんまです。難読・人名・地名・熟語などの読み方を提供するサービスになります。情報の取得元については、後述しますがYahoo!さんから頂いております。また、それとは別に下記二つのページへの直リンクを貼らせて頂いております。
今回のサイトでは、descriptionタグで自動的に該当の漢字の読み方を表示する仕様にしてあるため、例えばGoogleで『鬱』と検索した場合、ページタイトルの下に『鬱の読み方：うつ/utu』まで表示されるようになっています。要するに別に当サイトのページをクリックしなくても読み方自体は調べ終わるようになっています。ですのでクリックしてくださった方への付加価値の意味を込めてこれらのメニューを用意しています。
ニコニコ大百科（β） / weblio(類語辞典) / 人名漢字辞典 / Wikipedia / NAVEまとめ / OKWave / はてなキーワード / goo辞書 / Twitter検索 / GoogleMAP /
この部分に関しては今後の評判を見て取捨選択していければと思います。
例えば当サイトで『破面』と検索しても『アランカル』とは表示されませんが、ニコニコ大百科さんやwikipediaさんならユーザーが満足のいく反応を返してくれるだろう、といったように、当サイトではどうしてもカバーしきれない単語の補完をしたいという目的があります。
GoogleMAPについては、例えば『竜胆（りんどう）』『小鳥遊（たかなし）』といった珍しい地名を検索する機会があった場合、せっかくだからどこにある地名なのかもすぐに見てもらえればと思って貼らせて頂いてます。
友『アニメやマンガの流行りで海外の人も漢字の読み方や意味に興味を持ってる人が多いと思う。もちろん翻訳ソフトを使って確認とかもしてるとは思うけど、簡単に調べられるに越したことではない』
・『読み方は？』
『読み方』サイトの先輩サイト様方。今回の製作物では大きな違いは文字を大きめにしたことや、先述のとおりdescriptionタグに漢字の読み方を組み込んでネタバレ式にしたことなどが大きな違いになります。
先述とは別の友人からは『読み方系のサイトなんていくらでもあるから今更参入しても意味ないよwww』と笑われましたが、それでもまずとにかく作ってみる、やってみるというのが大事だと思います。
公開URL：http://developer.yahoo.co.jp/webapi/jlp/furigana/v1/furigana.html
・解説：
「漢字かな交じり文に、ひらがなとローマ字のふりがな（ルビ）を付けます。」（該当ページより引用）
「そもそも漢字の読み方サイトなんてどうやって作るんだよ?」という問題を解決してくれるのがこのAPI。これがないと始まりません。知らない人に説明すると、APIというのは、
APIとは、アプリケーションプログラムインターフェイスの略語で、プログラミングの際に使用できる命令や規約、関数等の集合の事を指す。 ソフトウェア開発の際、いちから全てを作ることは困難だが、APIを利用すればもともとあるプログラムをもとにして、自分でプログラミングすることなくその機能を利用したソフトウェアを作成することができる。
というもので、これで他所からサービスやデータの一部を借りることで新しいサービスの製作の助けになってくれます。いろんな所から出ているのでぜひ探してみてください。
・参考サイト様
『Yahoo!デベロッパーネットワーク』 ： http://developer.yahoo.co.jp/sitemap/
・解説：前回も使用したもの。Twitter社が提供するCSSフレームワーク。サイトデザイン（外見）に使用。
自動でレスポンシブ、適当に組んでもそれなりの今風サイトになるので便利。
・参考サイト様
『Twitter Bootstrap』 : http://twitter.github.com/bootstrap/
『Bootstrap 3.0入門 (全18回)』: http://dotinstall.com/lessons/basic_twitter_bootstrap_v4
③忍者ツールズ
・解説：前回も使用させて頂いています。ソーシャル要素はやはり外せないので今回も採用しました。
・参考サイト様
・解説：前回も使用させて（ryお気に入りとかの横に出る画像のあれですね。
・参考サイト様
『Favicon Japan!!』：http://www.favicon.jp/favicon_auto_create/ :
⑥その他
・使用サーバー
もし良かったら一度使ってみてくださると嬉しいです。ご意見ご感想頂ければなお幸いです。
読み方を複数表示したいのにどうしても1パターンしか出せませんでした。今後改善していければと思います。
自分はPHPはif文がギリギリ書ける程度の力量しかないので今回もヒーヒー言いながら作ってました。もし『WEBサービス作ってみたいけど敷居高そう』って人がいたらとにもかくにも作り始めてみてください！まずはじめるのが大切だと思います！
それではありがとうございました！
広告のクリック率考えるとPCの方がおまけになってしまうかもしれない。
詳細ページに回遊率を上げる仕組みが必要、逆にTOPページとかはアクセスないしどうでもいいっぽい。
もうあきらめた。
Bootstrap使っても自分では無理なのでフリーのテンプレートを使用。
「simple_html_dom.php」最高だと思う。
Librahack事件を忘れないように相手のサーバーを思いやる設定（時間と頻度）にする
無修正サイトなど国内法に触れるもの以外のアダルトサイトはGMO一択だと思う。
前回はDTIを使用していた。
前回は誰にも買われなかった。放置サイトはPPCがよいのかな。
Webデザインには
「はじめにAdobeありき。」
である。
全てのサイト合わせて月5000円以上儲かったら（道のり遠い）買ってみる。
広告のクリック率考えるとPCの方がおまけになってしまうかもしれない。
詳細ページに回遊率を上げる仕組みを作って、逆にTOPページとかアクセスないしどうでもいいっぽい。
Rails3 とTwitter Bootstrapで、オシャレなエロサイトをつくってみました。
http://anond.hatelabo.jp/20120708161051
bootstrap使ってもカッコよくできないよ？
プログラマー向けじゃないの？
CSS,Components,Javascript のタグにあるサンプルを全部作ってみた。
あまりの面倒臭さに一度諦めた。
その後色々調べたら「simple_html_dom.php」の存在を知る。
スクレイピング作業が一瞬にして終わった。
メールの設定がどうしてもできない。
エラーも出ていない。
一度諦めた。
info@xxxx.com
危ない名前は使わないのは基本だよね。
MyIsamだとインデックスに容量制限があるのでInnoDB使用
表示
出来あがったサイト
数1000件のデータなのでキャッシュやインデックスいらなかったかも。
デザイナーがプログラムやるのって後者の方が敷居は高いとは思う。
でもプログラムは勉強できるけどデザインってセンスがなきゃどうしようもない。
おわり
もう少しデザイン頑張ってみる。
デザインの教本読んでみると
10年くらいWeb開発業界にいて、ここ最近はRailsでアジャイルな高速開発的なものの周辺にいる。今は開発者〜マネージャの間を行き来しつつ顧客窓口〜実装まで一通りこなしている。
あちこち渡り歩いて色々なエンジニアと一緒に仕事をしたり、お客さんに頼まれてエンジニアの面接やらに顔を出したりすることがあるのだが、ここ最近のWeb開発はますます主力級のゴリゴリ書けるエンジニア（いわゆるフルスタックエンジニアと呼ばれるものも多分ここに入る）と大したことのないエンジニアの差が開いてきたように思う。
主力級のエンジニアは1〜2回がっつり打ち合わせしてプロジェクトの重要点とざっくりラフなイメージを共有すれば、どんなに遅くても1週間もすればプロトタイプが上がってきてお客さんに見せつつ微調整し、いわゆるアジャイルとかスパイラル開発的なことができる。デザイナがいなくてもBootstrapでとりあえず最低限の見た目を作ってくれるので、とりあえずデザイナ無しで開発して最終的にお客さんが気に入らなければWebデザイナに見た目整えさせてテンプレ取り込み、という開発がここ最近のメイン。
ソースコードもフレームワークやRESTfulの基本概念が理解されているコードなので、後日の機能修正の時にそのエンジニアが動けなくても自分がフォローして修正することもできる。
仕事もしやすいし、実質1〜2人の稼働でサクサク進められるのでコミュニケーションロスもなく楽しい。
一方、大したことないエンジニアは前述した流れが全くできない。
まず決定的なのは、開発が遅い。ちょっとしたデザイン無しのCMS（リッチUIなし）をRailsで書くのに1週間かかっても終わらなかったりする。これじゃ生PHPで書くのと変わらないかそれより遅いので、Rails使う意味がない。
次に、品質が低い。できあがったと言われて念のためチェックすると、基本的なCRUDレベルでエラーが出たり、お客さんに見せるプロトタイプだと言っているのに初期データ（seeds）の整備すらされていなかったりする。本人のローカル環境で動いてるけどstaging環境にdeployすると動かないとかはよくある。
パッと見に分からない部分もひどくて、ソースを確認すればあちこちどこかからコピペしてきたコードのつぎはぎで、HTML規約違反やJavaScriptのエラーまで放置されていたり。あと実装しましたと口頭で言っていた機能がソースコードコメントではTODOになっていたこともあった。
最後に、成長しない。開発上詰まった所なんかを主力級エンジニアに聞くのは構わないのだが、表層的な理解に留まり応用が利かない。30分〜1時間も主力級エンジニアの時間を浪費しながらもまた同じ様なところで同じ様なミスをする。自分もよくプチ勉強会みたいな状態になったときには参考図書や技術資料のポインタを投げたりしているのだが、参照先を見て深掘りすることはほぼない。
厄介なのは、こうした大したことないエンジニアも、Railsであればあちこちのチュートリアル記事や書籍を参考に、そこそこそれっぽく見える自作サービスくらいなら作れてしまうという点にもある。
彼らの作るサービスはまさに書籍やチュートリアルサイトのコピペの集大成だが、個人が趣味でやっているサービスとしては十分に動く。そして周りには「エンジニアです。個人でWebサービスも公開してます」となる。サービスの外からは内部のコード品質などはわからない。
プライベートで開発するのはむしろ奨励しているのだが、彼らはその拙い（あえて「拙い」と書く）サービスでもって「俺はもういっぱしのエンジニアだ」と勘違いしてしまっている様に思える。
だが違うのだ、お前が書いているシステムは「とりあえず動く」レベルのものであって、受託開発としてお金をもらってお客さんに納品するシステムや、数千万〜数億の売上を左右するような業務システムではその素人クオリティでは話にならないのだ。
適切な例外処理、担当者がミスしにくい管理画面の設計、お客さんの想定ユーザ数に耐えられるレベルでのスケールする設計、開発者が入れ替わっても保守が続けられるようにするための最低限のドキュメントなど、production level qualityに足りていない部分がいくらでもあって、そこまで考えられて「主力級エンジニア」なのだ。
こうした主力級エンジニアと大したことないエンジニアの谷は以前から感じていたが、ここ最近ではさらに顕著に感じるようになってきたように思う。
例えば、主力級エンジニアはRailsだけでなくミドルウェアやprovisioning（chefとかansible）、最近ではdockerやCI、AWSの新サービスなどについても各自追いかけていて、自分も含めてちょいちょい議論をすることがある。「最近のアレってどうなん？」とか「はてブでやたらXXX流行ってるけど、これって結局数年前のYYYの焼き直しじゃん」みたいな。
そんなところに大したことないエンジニアもはてブやRSSなどで用語は聞いたことがあるので混じってくるのだが、まず前提知識がなさすぎて議論にならない。大体「XXXマジすごいっすね〜（意訳）」で終わっていて、その技術の背景や今後どうなりそうか、自分達が取り入れることで業務効率や開発の楽しさが改善するのかといった視点がない。
他にも、ちょっとしたトラブルシューティングの際も、基礎がなさ過ぎて問題の切りわけができない。問題の原因がネットワークレイヤなのか、ミドルウェアなのか、アプリなのかすら判断できなかったり、そもそもアタリを付けるのが絶望的に遅かったり勘が悪い。
単に作業が遅いというのではなく、問題の切りわけというエンジニアとして最低限できないといけない事すらおぼつかないケースも見かける。
こうした大したことないエンジニアは速度・品質・難易度面で新規開発プロジェクトにアサインするリスクが高いので、必然既存サイトの運用・メンテ（ちょっとしたページデザインや文言修正）といったタスクが回されるのだが、最近この辺りも仕事がなくなってきているように思う。
というのは、お客さん側にRails Tutorial程度の開発知識を持っている元エンジニアや趣味でちょっと触ってみましたレベルの人が増えてきたから。これは恐らくRails特有な所（自作Webアプリ簡単に作れる啓蒙がなされている）がありそう。
ちょっと考えてみれば、文言修正やデザイン修正する程度の作業、外注に頼むと数万かかる上に見積やら稼働確保やらで数日〜数週間待たされるのに対し、担当者が自分でやってしまえばすぐに済む話というのはちょっと考えれば分かるわけで。
# もちろんそれでも保守契約や責任分解点の関係で外注するケースはあるだろうが、Railsを採用するようなWebサービスは速度重視のことが多い
そんな中、この「大したことないエンジニア」の人達はどうなるんだろうなあ、と思う。開発会社ではなくRailsシステムを運用しているユーザ企業に行けば多少は需要あるのかなーとも思うけど、ユーザ企業はできないエンジニア雇うほど余裕もないだろうし。
せめてコミュニケーションスキルが高いとかそういう利点があればいいんだけど、変に自分が「エンジニア」というプライドがあるのか、窓口とか管理方面は率先してやろうとしなかったりもするし。
早めに「エンジニア向いてないよ」と言ってあげるのが良いのだろうか？
http://individualist.link/ （←ドメインかっこいいでしょ）
〜 居酒屋にて 〜
A「やっぱり若者が稼ぐにはアプリ作るしかないと思うんですよ」
B「あー分かる」
C「ゲームは当たると大きくていいよね」
A「いいですよね」
A「そういう人の話聞いてみたいんですけどなかなか出てこないですね」
B「どういう人がどういうサービスで当てたのかまとめたい」
A「いいですねえ。Wiki 的な」
B「Google Docs とかでやってみる？」
A「おお、やりましょう」
B「Webサービスにしてもいいかも」
B「できた」
B「ドメイン取ろう」
アルコール入ってるから話のディティールうろ覚えだけどこんな流れで作りました。
当てたいなら先例を見るのが一番参考になるはずだし、僕は個人で作ったものが流行っているのを見るのが好きだし、そういうのとても興味ある。
このサイトを見ていると、どういう人がこのサービス作ったんだとか、これ個人で作ってたんだという発見があっておもしろいと思います。
１時間で出来たというのはほとんど誇張ではなくて、デザインに拘る時間とサーバーに設置する時間を抜かせば本当に１時間でできます。
・画像保存
・タグ付け
・JavaScriptで動き付ける
・CSS整える
・デザイン
というような感じになる。これらを実直にいちいち実装してたら１日で終わるか分かりません。
本を読む一番はやい方法は、文字を読まないことです。
ちょっとコードが書けると実装する道筋が思いついちゃうからライブラリを探す考えに及ばず実装しちゃう事があると思います。
そういう事は避けて、アプリを書くならアプリの本体を最小に済ませるか、ライブラリ自体を作ることに力を入れましょう。
こちらのサイトではRailsのレールに乗っかって開発しました。
以下の例はRailsを使った方法ですが、モダンなフレームワークを使っているのであればだいたい似たような話になると思う。
手に馴染んだフレームワークがあるならなんでもいい。
クソ小さなロジックと数ページしかないならPHPでもいいけど、
とにかくはやく作ることがしたいなら何かしらフレームワーク使ったほうがいい。
秘伝の Rails Application Template を用意しておくのも良い。
モダンなフレームワークなら何も考えずにデータベース接続できるはず。
Rails なら config/database.yml に接続情報書いて rake db:create && rails g model User name:string です。
ソーシャルアカウントでログインする要件が出たら、何も考えずに「あ、OmniAuth」となりましょう。
・画像保存
画像保存が必要になったら反射的に「Paperclip か CarrierWave どっにしよう」となりましょう。
・タグ付け
ActsAsTaggableOn を使います。
has_many :through のめんどくさいタグの実装ですが
これ入れて rake acts_as_taggable_on_engine:install:migrations && rake db:migrate を打てば一発で完成します。
・JavaScript で動き付ける
早くつくりたいんなら JavaScript は捨てましょう。
少なくとも生の JavaScript 書く時代ではないので CoffeeScript 使うと良いです。
・CSS 整える
とりあえず Bootstrap 入れましょう。
クラスの付け方を覚えちゃうと CSS 弄って HTML リロードして確認なんてことしなくても形は整います。
Bourbon gem 使って mixin ライブラリ組み込んじゃうのもいいですね。
HTML 書くのやめましょう。
Haml や Slim のようなテンプレートエンジンを使います。
Zen Coding でもいいけど、結局出力されるのが HTML じゃ見通し悪くて辛いと思う。
Web Components の時代になったらもっと簡単になるんだろうな。
・デザイン
ただ、Webページやアプリというのはだいたい決まったパターンがあるので、いろいろな事例を見るとよいでしょう。
正直レイアウト自体は他のサイト真似るのは悪くない判断だと思います。
むしろその方がユーザーにとって慣れ親しんだ分かりやすいサイトでもあります。
http://individualist.link/ の場合、http://www.producthunt.com/ を異常なほど参考にしました。
まあここまで書いてなんだけど、前提知識として Rails が使えるようになってないといけないのは敷居高くて悪かったと思う。
なお、今回つくったこのサイト、ぜひともみなさんにも投稿していただきたいのですが現在投稿者は承認制としております。
私本当に個人が作って運営しているというアプリやサイトというのが好きでして、
こちらのサイトにリストアップする行為に儲けやがってといった悪意は一切ありません。
