このブログシステムを10年以上メンテナンスしている須藤です。 このブログシステムは2008年5月から運用しています。Rubyを使って実現したいと思って運用開始時からtDiaryを使って実現していました。tDiaryはWebアプリケーションとして動かすことを想定していますが、このサイトはできるだけ静的なHTMLとしてコンテンツを提供したかったのでtDiaryで管理しているコンテンツを静的なHTMLに変換するフリーソフトウェアを開発してそれを使っていました。このたび、そのtDiaryベースのブログシステムをJekyllを使ったシステムに移行しました。 この記事を書いているのはJekyllに移行してなにか問題が発生していないか気づいた人がいたら教えて欲しいからです。気づいた人は https://gitlab.com/clear-code/website/-/issues にissueを作るか、直
VP of Technology の星 (@kani_b) です。技術基盤や研究開発領域などを担当しつつ、社内の色々なことを技術の力でいい感じにする仕事をしています。セキュリティや AWS の話が好きです。 さて、みなさんは、ご自身が勤務する会社の就業規則を読んだことはあるでしょうか。 エンジニアに限らず、会社の全スタッフが仕事をする上で関わってくるのが、就業規則や情報セキュリティドキュメントなど、会社のルールや規程を記す文書です。 特にセキュリティやインフラに携わるエンジニアは、その改訂も含め携わったことがある方もいるのではと思います。 よくある文書管理 こうした文書は、以下のように管理されていることが多いようです。 ベースドキュメントは Word 保存時は PDF で保存 版管理は Word の編集履歴 + PDF に保存する際のファイル名 編集は担当部門, 担当者のみが行う かつての
僕はいわゆるCMSが余り好きではありません。随分前に子会社のSYNCNEL事業のオフィシャルサイト(あるWeb屋がWordpressで制作)で苦い経験をしてからは特に。このブログもWordpressなので余り大きな声で言えたもんじゃないですけど(笑) でも、ホントはもうWordpressやめたい。ってかCMSにそもそも疑問を持ってます。 CMSの「おおげさ」感 サーバにシステム入れちゃうと、plug-inのupdateとか、CMS本体のupdateとか気になるし、ってか相性とかもあって出来なかったりもするし、そもそもシステムの為に必要なphp等の言語やDBやミドルウェアのupdateも気になって、脆弱性気になるけど…と余計な心配をしなくちゃいけません。 運用面でも、サイト全体の世代管理もしにくいし、ビジネス理由で別サーバに移転しようと思っても大変、htmlの構成を読み解こうとしてもテーマや
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 新規JekyllプロジェクトにBourbon, Neat, Bittersをインストールして作業したら、とても快適だった。 Bitters helps designers start projects faster by defining a basic set of Sass variables, default element style and project structure. – Bitters という説明の通り、新規プロジェクトがスタートダッシュできる感覚。最初からやりたいことに集中できる。 Bootstrapではスタート
「税金はどこへ行った？」というプロジェクトをご存知だろうか。 日経新聞やNHKなど大手メディアにも取り上げられているので、ご存知の方も多いかもしれないが、国民／市民である我々が払っている税金が何に使われているかを可視化するプロジェクトだ。もともとはイギリスで"Where Does My Money Go"という名前で始まったが、現在では日本を始め世界各地でこのプロジェクトに賛同したサイトが立ち上げられている。 百聞は一見にしかず。実際に見てもらうのが良いだろう。 「税金はどこへ行った？」とは？ 日本版の税金はどこへ行った？ Where Does My Money Go?を訪れてみて欲しい。2分少々のビデオがあるので、それを見るとプロジェクトの概要や状況がわかる。 WHERE DOES MY MONEY GO? 〜税金はどこへ行った ... このサイトの各地への広がりから、日本のいくつかの自
これまでも サービスAPI の更新や、それに伴う UI の変更など、小刻みな機能向上が図られていましたが、昨年11月、GitHub の ヘッダ、フッタが新しくなった のを皮切りに、12月には Gist のリニューアル と GitHub トップページのリニューアル が立て続けに行われました。 また今年1月には、ユーザー数が、アカウントベースで300万人を超えた そうです。 小さくかつ素早く、不断のサービス向上を図る姿勢が、ここまでユーザーを惹き付けた理由なのでしょう。 一方、公式ブログ を追いかけていくと、単に Git のリポジトリ・サーバーとして便利で使い易くする以上に、「自然に人が集まる魅力的なコミュニティ」を目指し、「誰もが気軽に参加できるオープンソース・コミュニティを創る」という意気込みのようなものを感じました。 人が集まれば、それだけビジネスの機会も増えるというワケです。 そこで今
※ これは Jekyll アドベントカレンダー の 25 日目の記事です このブログの生成にも利用している Jekyll が約 1 年ぶりにバージョン アップして 0.12.0 になった。RubyGems に公開されているので、gem update で更新できるはず。 この記事では、0.12.0 で個人的に注目している「シンタックス ハイライトに関する改善点」を 2 つ紹介する。 Jekyll の良さについては、俺の最強ブログ システムが火を噴くぜ で記事にしているので、知らない人はそちらからどうぞ。 Redcarpet 2 のサポート まず 1 つ目は Redcarpet 2 のサポート。 Redcarpet は GitHub の中の人によって開発されている Markdown パーサーて、GitHub Flavored Markdown が使えるのが大きな特徴。 これまでも Jekyll
この数年くらいで、主にプログラマのあいだに、「静的サイト生成（static site generation）」への人気が復活しつつあるようだ。 「静的サイト生成」の「静的サイト（static site）」とは、ウェブサイトのすべてのページが、あらかじめHTMLファイルになっているようなウェブサイトを指す。データベースなどを使わず、HTMLファイルを手作業で作っているようなサイトは、すべて「静的サイト」である。 「静的サイト生成」とは、手作りで「静的サイト」を作るのではなくて、HTMLファイルをプログラム的に「生成」する手法を指す。データベースやテキストファイルにある「データ」と、デザインを定義する「テンプレート」をプログラム的に結合して、HTMLページを生成する、というのが典型的な手法だ。この生成プロセスを受け持つソフトウェアが「static site generator」である（以下、こ
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ブログを「はてなダイアリー」から、自分のサーバーに移転しました。 せっかく移転するなら、2012 年の流行を取り入れた挑戦的なブログにしてみたい！と思い、構想から半年、ついにこの日を迎えることができました。 せっかくなので、凝ったところを自慢させてください。 これが俺史上最強のブログ システムだ ブログ システムとして Jekyll を採用 Jekyll のプラグインを自作 (はてな記法対応、英語ブログとの統合) 履歴管理は GitHub を利用、git push で自動でデプロイ コメント欄には DISQUS を採用、旧ブログへのコメントはインポート済み HTML5 マークアップ、CSS3、レスポンシブ Web デザインでのモバイル対応 盛りだくさんですね。 詳しく説明していきます。 ブログ システムとして Jekyll を採用 最近では WordPress を選ぶのが普通でしょう。Wo
ここ最近、jekyll に関する記事を目にする事が多くなりました。 以前から WordPress でオリジナルなブログを作ってみたいと思いながらも、なかなか重い腰が上がらなかった私が、なんとなく jekyll でブログを作り始めてみたら、以外にオモシロかった、という話をまとめてみたいと思います。 本来生まれも育ちも違う、WordPress と jekyll を比べる こと自体はナンセンスなので、jekyll でどこまでできるかが本記事のメイン・テーマです。 大抵は 「ブログなら、最低このぐらいの機能が欲しいよネ」 というのがあると思います。例えば、私も使っている Octopress では、カテゴリとタグを使い分けることが出来ません。またカテゴリを階層化したい人もいるでしょう。「続きを読む」的な機能だって、欲しいですよネ。 一方海外では、「WordPress から jekyll に乗り換えま
放置していた英語ブログをこのブログと同じデザインに統一した。英語ブログ、以前は MovableType を使ってたんだけど、いろいろ面倒になったので Jekyll で作り直した。Jekyll は Github Pages に使われている静的コンテンツ ジェネレータ。Ruby で作られていて、コードはシンプル、プラグイン機構もあるので、カスタマイズしやすい。Jekyll については次のページが分かりやすかった。Big Sky :: Jekyllで始める簡単ブログソースコードは https://github.com/nitoyon/tech.nitoyon.com で公開している。このブログも移動させようと準備中せっかく英語ブログも新調したので、このブログも http://tech.nitoyon.com/ja/blog/ あたりに移動させようと準備している。理由としては色々あるんだけど、ざっ
はてなダイアリー はてなダイアリーでははてな記法という、HTMLの簡略記法が使えます。この記法を利用することで簡単に整形された日記を書くことができます。私も６年間はてなダイアリーと、はてな記法のお世話になりました。 しかしはてな記法は、はてな独自の簡略記法なので他では使えません。従って一つの不安がよぎります。 この先もし10年、20年とブログを書き続けるとしたら、それははてな記法でいいのかと。 はてなダイアリーには別の不満もあります。次のようなものです。 HTML整形後の文章をローカル環境で確認できない。 記事に変更が生じてWeb上で直接編集した場合に、ローカルデータと内容が不一致となり、その管理が煩雑となる1。 あんなにサンプルがあるのに、イケてるデザインが見当たらない2。 基本的にサイトが重い。 Github Pages + Jekyll そんな理由から私はGitHub PagesとJ
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 （マークアップ） されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown （略して GFM） という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 （もちろん GitHub 初心者です！） の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ （レンダリング） を気にして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
