NFT完全に理解した！！になるために独自コントラクトでNFTを発行してみる方法の解説
この記事では ブロックチェーン全くわからんという人 を対象に NFT を独自コントラクトで発行する方法を解説する。いわゆる完全に理解したレベルになれることを目指す。 また、自分はまだこの辺りの技術のキャッチアップを始めたのが 2 ヶ月程度なので間違っている部分もあると思うがその辺りは指摘してもらえるとありがたい。 前提知識 まずは前提知識として理解しておくべきことが多いのでざっくりとそれぞれ整理する。ブロックチェーンの世界における開発は普通の Web の世界とは異なる部分が多いので最初に 全体像 を把握しておくことが重要。 基本用語 いきなり NFT の話を始めると知らない用語が多く登場してしまい面食らってしまうと思うのでまずは今後出てくる各用語の ざっくりとしたイメージ を書く。ちなみに簡略化するため Ethereum の話が中心になってしまうのでその点は注意してほしい。 ブロックチェー
IntelliJ IDEAの動作が遅い時の対策 - a tomato
普段は、InteliJ IDEAを使って開発しているのですが、メモリの初期設定が以下のようにかなり少ないです。 初期状態で開発を行うと、アプリケーションの規模によっては内部indexの作成に時間がかかりかなりストレスが溜まります。 開発のストレスを少しでも軽減するために、設定の変更で利用するリソースを適切に調整して対処を行います。 -Xms128m -Xmx2048m -XX:ReservedCodeCacheSize=240m -XX:+UseCompressedOops そこで、端末のメモリ状況に合わせて、ヒープサイズを増やします。 Intelijを起動して上部のHelpメニューないから下記の項目を開きます。 すると以下のようなファイルがIntelij内で開かれます。 ここの数値を今回は、以下のように変更します。 -Xms2G -Xmx4G -XX:+UseG1GC -XX:-UseP
ゼロから学ぶ C++
ホーム 1. C++ を始める 2. 基本構文 3. コンテナ 4. ファイル分割とスコープ 5. ストリーム操作 6. メモリの管理 7. クラス 8. キャスト 9. テンプレート 10. エラー処理 11. ビルドとライブラリ 12. メモリレイアウト 単体テスト デバッグ ビルド自動化 付録 このサイトは C++ について説明した学習サイトです。 本書を通じて C++ の開発環境や構文・単体テストの書き方などが 一通り学べるようになっています。 対象¶ C++ を初めて学ぶ人 プログラム言語を 1 つ以上経験したことのある人 関数やクラス・オブジェクト指向に対する知識をある程度前提にします。 C++ の特徴¶ C++ は ビャーネ・ストロヴストルップ により開発されたプログラミング言語です。 C++ には主に次のような特徴があります。 高パフォーマンス メモリ使用量が少ない 柔軟性
使徒がそこにいるような、空と調和した巨大ARオブジェが出現 スマートフォンアプリ「Fakeye」、ベトナム研究チームが開発
空と調和したAR表現を実現するには、手前にある物体が背後にあるARオブジェクトを隠して見えないようにするオクルージョン（隠蔽）を正確に行う必要がある。今回の手法では、機械学習のロジスティック回帰モデルを用いて、空のセグメンテーションを計算している。 また、空を完全に置き換えるのではなく、リアルとバーチャルのシーンを混合したテクスチャブレンディングを行い、空の質感を維持した表現にしている。例えば、雲の後ろにARオブジェクトを配置する場合、完全に見えなくするのではなく、部分によっては適切な透明度を設定することで物体が雲から薄く透けて見える表現になっている。
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
1行直すだけってそんなに大変なの？
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
「工数一日」は「明日できる」じゃない！エンジニアと非エンジニアのギャップとは - paiza times
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 ディレクターやプロジェクトマネージャーといった非エンジニア職の方々は、エンジニアとコミュニケーションをとることに難しさを感じたり、考え方にギャップを感じたりしたことがある方もいらっしゃるかと思います。 「エンジニアとわかりあえない…」「エンジニアが何を考えてるのかわからない…」という方のために、エンジニアとのトラブルのもととなるやりとりや、気を付けるとよいことを考えていきますので、非エンジニアの方々の参考になればと思います。 ■「どれくらいでできる？」はその場で決められるものではない 非エンジニアとエンジニアのもめごとの原因で多いのが、スケジュールに関することです。 非エンジニア「この機能どれくらいでできる？」 エンジニア「一日でできます」 非エンジニア「じゃあ明日リリース
テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
「UnityでiPhone向け3Dゲームを作る」レポート - ゲームの花園
本日「3DCGツールとUnityによるゲーム開発実践セミナー」に参加してきました。 そこで講演されたセガさんのUnityを使ったiPhoneアプリのグラフィックの最適化の話が、大変濃かったのでレポートします。 2012 / 02 / 24 07:40 追記 Game Watchさんにレポートが上がりました。写真が豊富でわかりやすいです！ http://game.watch.impress.co.jp/docs/news/20120223_514183.html 講師 株式会社SEGA チーフデザイナー 築島智之 概要 セガさんで走っている、Unityを使ったiPhoneアプリのプロジェクトから出てきた、グラフィック最適化のノウハウの総括 レジュメ iPhone4で3Dを快適に動かす方法 iPhone4の特徴 最適化の方法 シーンの管理方法 ゲームエンジンとコンテンツ工学 環境 Maya 2
Unity 5の新機能FrameDebuggerでグラフィックパフォーマンスを改善する - Qiita
追記：2015年11月27日 本記事の旧タイトルは「Unity 5 Proの新機能FrameDebuggerでグラフィックパフォーマンスを改善する」でしたが、これは本記事がUnity 5リリース前に書かれたためで、Unity 5正式版は無料版PersonalでCloud、Team Licenseなどのアドオンを除くエディタ上の全機能が使用可能になったため、本記事から「Unity 5 Pro」の記述を取り除きました。 Unityアプリのパフォーマンス最適化 UnityはMonoを採用しているため、C++やObjective-Cのようにネイティブのバイナリコードが出力されるわけではなくMono Virtual Machineで動作する中間言語が出力されそれを読み込んでアプリを実行しています。（iOSでは規約のためネイティブに事前コンパイルされています） と言っても現在ではCPUの性能が向上し、
5分で絶対に分かるAPI設計の考え方とポイント
API設計を学ぶべき背景と前提知識、外部APIと内部API、エンドポイント、レスポンスデータの設計やHTTPリクエストを送る際のポイントについて解説する。おまけでAPIドキュメント作成ツール4選も。 【0分】API設計を学ぶべき背景 APIの公開が増えている 最近、自社で保有するデータや、システム、アプリケーション、Webサービスの機能を「API（Application Programming Interface）」として公開する企業が、増えてきています。これに伴い、「API経済圏（APIエコノミー）」という新たなビジネスモデルが確立されつつあります（参考：5分で絶対に分かるAPIマネジメント、API経済圏）。 「ProgrammableWeb」というAPIに関するニュースサイトや、さまざまな企業が提供するAPIのリンクがまとまったサイトもあり、APIの普及はものすごいスピードで進んでいる
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
俺が勝手に考える正しいMVCの実装。モデルはデータAPI！ - はかますたいる！きょろの技的雑記
最近、一緒にコードを書く人（特にRailsから始めた学生さん）に、 MVC（Model - View - Controller）において、「model = DB」だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。 あくまで俺の考えなので、違ってたらごめんね。 MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく！ 初学者はViewをモリモリ生やす これはプログラミングを始めた人なら誰でも経験ありますよね。 むしろ、MVCとか始める前の、誰でも経験あるであろう <?php print '<a href="${hoge}">link</a>'; なんてのは完全にViewだけで実装されたプログラムですね。 最近のMVCのテンプレートはとても高機能です。 変数の宣言も、条件処理も、ループも、プログラム言語としてひと通りの「逐次、反
簡単インストールから始める初心者のためのRuby on Railsチュートリアル
Railsは、その名の通りプログラミング言語「Ruby」向けのWebアプリケーションフレームワークです。オープンソースで開発が続けられています。 よく見られるWebサービスは、データベースにデータを保存し、ブラウザーを使ってその入出力を行います。そのようなアプリケーションを作る場合、開発者はRailsを使うことで高い生産性を発揮することが可能です。 また、Railsはフルスタックなフレームワークなので、さまざまなタイプのアプリケーションを作ることができます。例えば、Androidアプリケーションに向けてJSONやXMLを出力するサーバーサイドに限ったアプリケーションを作ることもできます（参考「Androidアプリちょい足し開発レシピ（2）：TwilioとRailsで作る、電話でテキスト読み上げアプリ」）。 近ごろはエンタープライズ領域での採用も多くなり、業務システムのクラウド化をRails
湯河原の老舗旅館が「開発合宿プラン」 元SEの旅館主人が発案
湯河原の老舗旅館「おんやど惠（めぐみ）」（湯河原町宮上、TEL 0465-63-3001）が現在、「開発合宿プラン」を提供している。 「おんやど惠（めぐみ）」の「開発合宿プラン」で利用する会議室 現役エンジニアの開発作業を応援することを目的とした同プラン。プロジェクトのメンバーが日常と異なる環境で効率よく開発作業を進行できるように、会議室の24時間利用やWi-Fi環境の整備などのサービスを充実させ、快適な開発環境とおもてなしを提供して利用者から喜ばれている。 同旅館を経営する室伏学さんは元システムエンジニア。1988年から1996年まで8年半にわたりプログラミング言語と格闘。結婚を機に全く畑違いの旅館経営に従事することになった。当時出たばかりの「Windows95」のノートPCと共に湯河原に移り住み20年がたった。 「湯河原は東京駅から約70分、横浜駅からはわずか50分、湯河原駅からはタク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GUIアーキテクチャパターンの基礎からMVVMパターンへ