2014年6月13日から約2ヶ月間に渡り、岐阜県大垣市で「コア・ブースター・プロジェクト2」というプロジェクトを開催しました。 このプロジェクトは、地場産業と情報産業という異分野をかけあわせ、新規事業につながるイノベーションを創出することを目的としたものでした。そのために19社から24名の参加者が集まり、多様な視点や知識を持ち寄って共にアイデアを創出し、自らの技術等を提供し合い、実装しました。 複数の企業間のプロジェクトにおいては、プロジェクトの内容、各企業の役割分担や責任、知的財産の取り扱い等を厳密に定めた契約書を締結するのが通常です。しかしながら、既に何をつくるかが決まっている段階ではなく、0から1をつくろうというプロジェクトの初期段階において、事前に詳細までを定めることは不可能です。また、数社間であればまだしも、20社近い参加企業で契約書を締結するのはほぼ不可能です。仮に締結できたと
昨今、多様な参加者が参加して共にアイデアをつくる「アイデアソン」、それをソフトウェアとしてつくる「ハッカソン」、さらに見たり、触れたり、感じたりできるものも含めてつくる「メイカソン」が盛んに開催されるようになりました。そうしたイベントでは、多様なスキルや視点、経験を持つ人々が競争することで知的財産が創出され、事業化に向けて進めていこうという事例もでてきました。こうした状況により、イベントの主催者や参加者間において、知的財産を適切に扱うためのルールが求められています。 また、参加の動機や期間中の貢献度、その後リスクをとって事業化まで進めていきたいと考えるかどうかは同じチームの中でも参加者ごとに異なります。時間が経過した後のトラブルを避けるためにも、終了後に参加者間で成果物とその後の扱いを確認し、書面で残しておくことが望ましいのですが、なかなか難しいというのが実情です。 そこで、主催者側、参加
いま、PCゲーム業界、いやゲーム業界全体で最もホットな企業と言えば、「Valve」を置いて他にいないだろう。 元々、『Half-Life』という一本のFPSからスタートしたこの企業は、やがてアクティブユーザーが1000万人を超えるPCゲーム用ダウンロードツール「Steam」を開発し、 更には、賞金総額22億円の大会が開催された『Dota 2』や『CS:GO』のようなe-Sportsタイトルまで介入し、衰退しつつあったPCゲーム業界の可能性を引き上げた。 さりとて、この大企業「Valve」によるイノベーションはどのように生まれたのか。そして同時に、ごく僅かの採用枠を勝ち抜いた新入社員たちには、どのような活躍を期待されるのか。 少なくとも、この新入社員用マニュアルからは、Valveの求める人材の水準がどれほど高いものか、窺い知ることが出来ると思う。2万字以上に及ぶ長大な内容だが、もし読んでいた
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
良い記事を書くためのガイドラインこのガイドラインについて Qiitaは、プログラミングに関する知識を記録・共有するためのサービスです。Qiita上の記事は、投稿者以外の人にとっても価値のある記事であることが望まれます。 あなたの知識が他の誰かの役に立つようにするために、このガイドラインを参考にしてください。 役に立つ記事を書くために Qiitaに投稿した記事はフィードに表示され、他のユーザーが目にすることになります。また検索から記事を見つける人もいるでしょう。あなたの記事が読んだ人の役に立つかどうかを意識してみましょう。 自分用のメモのつもりで書いたものでも、少し気をつけるだけでぐっと価値のある記事にすることができます。 意識すると望ましいもの 具体的で簡潔なタイトルをつける 記事のタイトルは、記事のページだけでなくQiitaのフィードや検索エンジンの検索結果にも表示されます。タイトルを見
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRu
Instructions on how to generate docsets (for Dash) are found below. There is no method that is best for every case, so you'll have to consider all and decide which is the best for you. When your docset is ready, please contribute it to Dash. Generate docsets from: 1. Swift DocC Documentation 2. Python, Sphinx or PyDoctor-Generated Documentation 3. Javadoc-Generated Documentation 4. RDoc or Yard-Ge
Selling a structured settlement can be a complicated process, but it’s well worth the effort. If you’re looking for a way to get cash quickly, selling your structured settlement is the best option. In this article, we will discuss the process of selling a structured settlement and provide you with all the information you need to make an informed decision. What is a structured settlement? A structu
Sketch, markup, code, style, test, and then deploy. Weblog Documents Projects About Hail2u.netで使われているマークアップやスタイルの解説兼プレビューのページです。マークアップはHTMLのソースを、スタイルについては全ての変更履歴を含むGitリポジトリかこのページで参照されている非圧縮のCSSファイルを参照してください。このページに限ってはマークアップにおかしいところが多々ありますが、その多くはプレビューを作る上でのやむを得ない事情によるものです。 バージョニング フォーマットはSemantic Versioningを使っています。ただしAPIの変更などというものはあまりないので、以下のような条件でバージョン番号の増加を行っています: メジャー・バージョンは、レイアウトの大幅な置き換えやテーマカラー
背景 APIドキュメントを書くのが楽になるツールまとめ - Qiita iodocsで便利なREST APIドキュメントを作成する - Qiita これまでずっとREST APIドキュメントをwiki上で管理していて、重たいページ上で特殊記法使ったり、スタイルの調整に時間を取られるのが辛かった。そこで良さげなドキュメントツールを色々調べてたんだけど、最終的にapiary.ioが一番良さそうという結論になってきた。 このサービスの主な特徴。 markdown記法でAPIドキュメントを記述できる ドキュメントの生成と同時にAPIのモックサーバを用意してくれる サインアップから5分くらいあればドキュメント公開できる。ドキュメントのホスト先を気にしなくてもいい。 特にドキュメントと一緒にモックを作ってくれるのは他にはないポイントでかなり便利。 使ってみる サインアップはGithubアカウントで h
さいきんREST APIのドキュメントを書いていて、wiki使うのだるいし他に良い方法ないかな〜と調べてた時に見つけたツール群をまとめてみます。 追記: こちらも便利そうなので参考にどうぞ。 REST APIドキュメント作成ツールはapiary.ioが決定版かもしれない - Qiita swagger Swagger: A simple, open standard for describing REST APIs with JSON | Reverb for Developers デモ: Swagger UI ソースコード中にAPIの概要を書いておくと、それを元にドキュメントを自動生成してくれる。wikiやmarkdownで書くのと決定的な違いは、↓のようにドキュメント上のformからAPIコールを試すことができる点。 様々な言語のWAFに対応したライブラリも開発されてる。 Home ·
HTMLシンタックス インデントには半角スペース2個分のソフトタブを使用すること。これが全ての環境で全く同じように見せる唯一の方法。 ネストされた要素はかならず1段階だけインデント(半角スペース2個)すること。 いつもダブルクォートを使うこと。属性値に対してシングルクォートを使わないこと。 閉じタグの無い要素に対して、末尾のスラッシュは省く事。HTML5仕様に省略して良いと書いてある。 省略できる閉じタグを省略しないこと。(例えば</li>とか</body>)。 <!DOCTYPE html> <html> <head> <title>Page title</title> </head> <body> <img src="images/company-logo.png" alt="Company"> <h1 class="hello-world">Hello, world!</h1> </
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it. For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release
CSSはどちらかと言えばやさしく、雑にコードを書いてもなんとかなってしまう言語です。 しかし、雑にコードを書いてしまうと、昨日書いたこのコードなんだっけ？ とか、新しくスタイルを増やすと別のスタイルがおかしくなってしまうことはありませんか？ 大規模なプロジェクト、長期に渡るプロジェクト、複数のメンバーが関わるプロジェクト、そして明日の自分も一年後の自分も使える、メンテナンス性に優れた一覧性のある美しいCSSを書くのに役立つガイドラインを紹介します。 CSS Guidelines 2 CSS WizardryのHigh-level guidelinesの最新版（2014年8月リリース）。 大規模で長期に渡るプロジェクト向けのメンテナンス性に重点をおいたスタイルシートのガイドラインです。スキルの異なる制作者、新規で加わる制作者などでも、統一されたコードでの制作が可能になるのを目的としています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
