このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
シンプルなHTMLでセマンティックに実装することにこだわった、アクセシブルでレスポンシブ対応のサイトをより簡単に制作するためのフレームワークを紹介します。 MIT Licensesで、個人でも商用でも無料で利用できます。 Turret Turret -GitHub Turretの特徴 Turretはアクセシブルで、セマンティックで、レスポンシブ対応のサイトをより簡単に制作するためのフレームワークです。 レスポンシブ対応 読みやすいマークアップを使い、レスポンシブ対応のグリッドやエレメントを汎用性に優れたclassを使って実装しています。 Design First 直感的なユーザインターフェイスのために、文字の定義とカラーパレットにフォーカスしています。 No JavaScript スクリプトは使用せず、LESSベースでネイティブのWeb要素を採用しています。 セマンティック マークアップは
はじめに このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。 まとめ 昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。 クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。 そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。 発表資料&箇条書きで振り返る最近の動き AWS Casual Talks #3 https://github.com/myfinder/aws-casual-3/blob/master/slide.
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサ
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
2016/04/06追記 はてなブックマークの「一年前の話題」だとかでやたら人が来てたので、一年前の一年後(つまり今)の状況を記しておきます。 ↓ http://gyuque.hatenablog.com/entry/2016/03/28/215253 今年はSFC 25周年である。大学ではなくスーパーファミコンのことである。 @pornanime いいからスーファミでピコピコしてろよな。— カザオカマリ (@ykzts) March 16, 2015 スーパーファミコンを買ってもらったのは小学校に上がった頃か、日焼けして真っ茶色になってはいるが未だに動作し、手元に置いてある。共に育ったマシンなので美しい思い出を語っては上のように若造に馬鹿にされているのだが、よく考えるとこれだけ思い入れの深いスーパーファミコンで動くプログラムを書いたことはなかった。プログラマーとしてこれは誠実ではない、と
GitHub on steroids Browser extension that enhances GitHub code review and exploration. Features * Fast IDE-like code tree * Quick search in tree format * Bookmark repos, issues, PRs, files * Support GitHub themes * Support private repositories * High performance, working with repositories of any size PRO features * File icon themes * Code font settings * Quick PR navigation * Unlimited bookmarks *
Node.js Advent Calendar 2013 - Adventar 9日目です。 あまりネタを用意する時間がなかったので、GitHubにNode.jsのリポジトリを置いたりnpmにパッケージを公開したりしたときに便利な定番サービスを3つ紹介します。 Travis CI Coveralls David タイトルは釣りですが、特にTravisとCoverallsは一度体験すると離れられないぐらいほんとにlife changing。コードをpushしたらブランチのビルド結果をプルリクに表示してくれたり、カバレッジ結果をコメントで書き込んでくれるので、それを見ながらコーディングを進めていけます。これが無料なのは意味不明なぐらいの神です*1。 サンプルコードはこちらのプロジェクトで見てください。 Github: https://github.com/teppeis/fixclosure
少ない手間と知識でそれなりに見せる、ズルいデザインテクニック with Sass / Compass (English Version) https://speakerdeck.com/ken_c_lo/zurui-design-technique-english-version 第一回…
DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不本意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い
アドビがオープンソースとして公開している「Brackets」は、HTML5とJavaScriptで作られたHTMLエディタです。アドビ自身はBracketsについてブログやプレスリリースでのアナウンスは何もしておらず、Github上にAdobeのコードとしてひっそりと公開されています。 アドビには統合的なWeb開発環境として確固たる地位を持つDreamweaverがありますが、Bracketsの画面を見るかぎり、目指すものはDreamweaverを置き換えるようなものではなく、もっと直感的で軽くシンプルなHTML/CSS/JavaScriptエディタを実現しようとしているように見えます。 Bracketsはまだ開発が始まったばかりで、それほど多くの機能が実装されているわけではありません(実際に起動してみましたが、短時間では使い方もよく分かりませんでしたし……)。今後もう少し機能が追加されて
Instagramは日本のユーザーも多く、日常を切り取った写真がほとんどで、 またお洒落なものも混じっているのでたまに眺めると気持ちがホッコリしたりします。 特定のキーワードでInstagramの最新の写真を検索したい時があります。 例えば、みんなが今どんな「ご飯」を食べているのか、今日の「日の出」はどのような具合なのか、 がInstagramの写真を通して分かるかもしれません。 Instagramの写真検索サービスを探してみると、 Instagram自身が検索機能を提供してないので他の第三者が作ったサービスがいくつか出てきます。 使ってみたところ、もう少し自分で見た目やら機能を変えてみたいなーなんて思いました。 そこで、「Instagramの今の写真を検索できるサービス」といういわばWebサービスを作りたい欲求にかられます。 今回はこのようなちょっとした欲求から考えた「Webサービスのモ
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く