  |
はてなキーワード: パーミッションとは
nginx、PHP-FPM、Laravelという構成なのですが、failed (13: Permission denied)というエラーが表示されて動きません。どうしたらよいと思いますか。
「failed (13: Permission denied)」というエラーは、通常、Nginxがアクセスしようとしているファイルやディレクトリに対して必要なパーミッションがない場合に表示されます。このエラーを解決するためには、以下の手順を試してみることができます。
Nginxがアクセスしようとしているファイルやディレクトリのパーミッションを確認します。ファイルやディレクトリが適切なパーミッションであることを確認し、Nginxが読み取りや書き込みを行えるようにします。
Nginxがアクセスしようとしているファイルやディレクトリの所有者とグループを確認します。Nginxの実行ユーザー（通常はwww-dataやnginxなど）がファイルやディレクトリの所有者やグループと一致するか確認し、必要に応じて所有者やグループを変更します。
サーバーがSELinuxを実行している場合、SELinuxのセキュリティポリシーがNginxのアクセスを制限している可能性があります。SELinuxを無効化するか、適切なセキュリティポリシーを設定することで問題を解決できる場合があります。
Laravelプロジェクトなどの場合、アプリケーションの一部ファイルが壊れている可能性があります。再度アプリケーションをデプロイしたり、必要なファイルを再生成することで問題を解決できるかもしれません。
上記の手順を順番に試してみてください。また、エラーが特定のファイルやディレクトリに関連している場合、具体的なパーミッションや所有者情報を提供していただければ、より具体的なアドバイスをすることができます。
viとemacsはどちらが優れているか? また、これら2つの方法の違いはどこにあるのか? さっそく設定を変更して実行してみた。-emacsはosのディストリビューションなのでインストールにはいくつかの課題が存在する。-emacsはunix系のosなので適切なディレクトリパスが設定されていない(*1)(apacheのモジュールとmysqlさえ設定しておけばいい)、各モジュールのディレクトリパスが適切に設定されていない、ファイルのパーミッションが適切ではない等
今の40代オタクがボクの師匠、プログラムもCGもDTMも師匠のおかげを書いた増田です。
お前が技術を中心に情報補完しろよと言われたので知っている範囲で情報を補完します。
ただやっぱりネタバレするとゲッサン編集部や作者氏から叱られそうなので、まったく本編には影響しないであろう部分を中心に情報補完させて貰います。
先に謝っておきますがネタバレ回避を考えたら第1話で語れる部分がココしかなかったっす・・・。
主人公の和田一馬が所持するガラケーはデザインに微妙な違いがあるけれど、おそらくはau W41CAで2006年の春モデル。
W41CAはペンギンケータイとも呼ばれたCASIOのヒット機種で、外観はCASIOらしく少々無骨、旧機種のW31CAでは赤外線通信やおサイフケータイへ非対応だったものの、W41CAでは対応を果たし全部入りケータイになった。
ペンギンケータイの由来ともなるマスコットキャラクターのアデリーペンギンが画面上の様々な部分で演出として登場し、ポップなオレンジの筐体色とも合わせてその可愛らしさから人気を博した。
W41CAは無骨さの中にある可愛らしさで人気となったが、CASIOのWn1CAシリーズは本来サラリーマンに高い評価を受けていた端末で、WordファイルやExcelファイルを閲覧できるPCドキュメントビューワーやPC向けWebページを閲覧できるいわゆるフルブラウザを搭載しつつ、USBマスストレージ接続が可能な端末であり、更にはFMラジオを受信できるなど当時のギークからも非常に高い評価を得ており、CASIOガラケーの銘機としてガジェット界隈では歴史に刻まれている。
当時を知る者であれば常識的な話だが、CASIOというか当時のauは学生へ対して強く訴求する携帯電話通信キャリアで「学割と言えばau」という認識が世間でなされており、auや携帯電話へ搭載する機能や展開するサービスも学生を意識したものが多かった。
取り上げているW41CAも着メロの最大発音数は128のステレオ再生、PCM音源の再生機能である着うた(AAC/48Kbps)にも対応していた。しかもSD Audio Playerを搭載しておりminiSD(microSDではない)にUSBマスストレージ経由で保存したAAC(96Kbps)の再生が可能であった。
ちなみにヒロイン(？)が使っている携帯電話は現在でもINFOBARを生み出したとして話題となるau design projectの第3弾端末であるau talby。2004年冬モデルで製造は三洋、型番がA5508SA。デザイン以外に語る部分がぶっちゃけない。
というか当時からハードウェアスペックに関して語られることがあまり無かった機種で、掲示板などで携帯電話のスペックを誇ったり最大限に活用するための情報交換などをするギークなユーザが選ぶ機種ではなかったので殆ど知らないというのが実情。
INFOBARは目新しさもあって結構いろいろ情報交換されたものだけれど第3弾ともなると正直言って失速気味になっていた。
ただ、主人公が最新の携帯電話でヒロインが型落ちのデザイン重視な携帯電話、学生なのでauという細かな描写は作者の意気込みを感じる。
個人的にはこの時期の携帯電話を挙げるならauではなくVodaphoneとNTT DoCoMoから発売されていたNokia 6630を推したく、これがまたSymbian S60で・・・と話が逸れるので別の機会に。
W41CAに搭載されている音源はYAMAHA AudioEngine MA-7i(YMU791)で、前述の通りFM音源の最大発音数は128でステレオ再生が可能であり、AACやMP3のデコードへ対応するなど非常に多機能で多くの携帯電話端末に採用されることとなる2005年に登場した最新LSIによる音源だが、W41CAでは何故かMP3デコードなど一部機能が制限されている。
着メロ形式はSMAF(MMF)で150Kbyte(153,600byte)まで、FM音源の使い勝手としては4オペレータの最大発音数128で、更にFM音源側の最大発音数を減らすことで最大16bit/12,000HzのPCM音源データを使うことが出来、同様にFM音源側の最大発音数を減らすことで着うた登場前後に一瞬だけ流行ったボーカル付き着メロで活用されたHV(合成音声)も使える。
エフェクターなども内蔵しておりMA-7シリーズは当時の着メロ職人からはかなり評価の高い音源であったものの、NTT DoCoMoしか注目しなかった頭内定位を利用した仮想サラウンド再生のための3Dポジショニング機能も実装されており、いつの世も空間に対するオーディオというのは経営者と技術者の心を掴んでしまうんだなと林檎マークを見て思いを馳せる。
ただ人気だったW41CAにも欠点はあり、当時のケータイアプリ開発者から悪名を欲しいままにしたezアプリ、つまりBREWアプリが採用されていた。当時のauは野良アプリ(勝手アプリ)開発者を締め出すことへセキュリティの都合上から躍起となっており、公式ez web以外の経路からのアプリインストールを著しく制限していた。
この制限が無くなるのは平成ヲタク リメンバーズの時間軸で言えばほんの先の未来である2007年に登場するオープンアプリプレーヤー(OAP)を待つ必要があり、W41CAは、というかau端末はその点からギークに毛嫌いされることがよくあった。
BREWアプリの欠点はそれだけでなく、これはBREWアプリよりも前のezplusアプリ時代からそうなのだが1日のアプリ内携帯電話パケット通信3MB制限という謎の縛り(後に6MBまで上限緩和)が設けられておりユーザとケータイアプリ開発者双方からヘイトを買う一因となっていた。ちなみに他社は1度のパケット通信量の上限はあったが1日の上限は無い。
いやそもそもQualcommからカフェインよりもアルコールだよと騙され酔っぱらいJAVAからBREWへ乗り換えたこと自体が愚かで、他社はJAVAのままなので単に開発負担が増え、auで公開されるケータイアプリが減るという結果しか生まなかった。これが解消されるのが前述したOAPであり、OAPの正体はBREW上に構築されたJAVA VM環境であった。
しかしこのOAPもBREW側のセキュリティパーミッションのせいでパケット通信するたびに通信を許可するためのダイアログが表示されるなど不便極まりない仕様であったためユーザの反感を買ってしまう。
マニアックなネタばかり詰め込んでもアレなので、平成ヲタク リメンバーズの本編に影響しないよな？とビクビクしながら選んだのが当時流行っていた携帯電話を活用した位置ゲームのコロニーな生活。当初はウィルコム端末向けだったが後に他の携帯電話通信事業者にも対応し、2005年にコロニーな生活☆PLUSとして改称アップデートされた。
このコロニーな生活☆PLUSはブラウザゲームの一種でコロニーな生活☆PLUSのURLへアクセスするだけでゲームへ参加できた。1km以上の直線移動距離を稼いでゲーム内通貨を貯め、自分の土地の施設を充実させ住民人口を増やしていくというゲーム。
当時を知っている人ならばオチが直ぐにわかっていると思うので間を置かず言ってしまうと、コロニーな生活☆PLUSの略称はコロプラ、現在では白猫プロジェクトやディズニーツムツムの開発元で知られる株式会社コロプラの祖業である。ちなみに今でも一応はスマートフォンアプリでサービス継続しており名称も「コロプラ」へ改称している。
平成ヲタク リメンバーズの世界の時間軸にプレイヤーは存在するだろうけれど今後ネタ被りしたら申し訳ない。
ネタバレ回避も必要だし始まったばかりの第1話でとやかく言えることはないですね。読者の興味を惹こうとする単語が現れたりするので走り出しとしては及第点なんじゃないかなと。
むしろ前述したように登場するガジェットをしっかりと時代に合わせたものにしていたりとセリフやキャラクターだけでなく登場する小物にも注目したほうが楽しめるのかも知れないというのが第1話への感想と今後への期待です。
作者氏は同年代だと思われるので、敵に回すと恐ろしいが味方につけると頼りないと言われるVIPクオリティを発揮してくれたらなと楽しみにしてます。うはｗｗｗおｋｗｗｗｗｗ
2月10日に"Web3"を痛烈に批判する Web3って流石にヤバくないか？ という記事が話題になっていたので拝読した。
過激な内容に加えて、非常にセンスとユーモアに溢れる文章で楽しく読ませて頂いた。
さらに、そのアンサー記事として2月12日に出ていた Re: Web3って流石にヤバくないか？ という記事も読ませて頂いた。
こちらの方も業界に非常に精通されていて非常に的を得た反論が展開されていた。
両記事を読む中で、少し補足したい部分がいくつかあったため、遅ればせながらアンサー記事に対して自分の考えを補足する形で書いていこうと思う。
https://anond.hatelabo.jp/20230212193550
本当の意味で、最も理想的に分散されているのはビットコインだが、ビットコインは本体も関連プロジェクトも、エンジニアに対する金払いは悪い。というかほぼボランティア。精力的に活動しているのはビットコイン長者の老人だけで、将来にわたっての開発の持続性がない。そもそも若い世代は育つはずがない。ビットコインはその大半が採掘されていて、これから人の一生分かけて、残り僅かな枚数のコインがちびちび採掘されて、すでに固定化されたマイナーに払われ続けるだけだ。自分が一枚も持ってないビットコインのために誰が働こうと思うのか。
ビットコインのコア開発者になろうとする人は確かにいないかもですね。だってもう開発する追加機能自体がないんだもの。ビットコインのコア開発者に今からなりたいって人がいたら、私だって止めますね。
広く捉えるとビットコイン含めたL1チェーンの開発の持続可能性に課題があるという話と理解した。
開発者のインセンティブという意味では、L1チェーンが利用され、Profitableである限りは通貨の価値が上昇するため、イーサリアムなどの多くのチェーンでは財団がGrant (開発支援金) を出し続けることができると思う。
チェーンがProfitableである基準については『The first profitable blockchain』( https://newsletter.banklesshq.com/p/the-first-profitable-blockchain )が詳しい。
ビットコインは機能追加を積極的にしないという哲学があり、そもそも開発するものがないという話は確かにあるが、仮に外部環境が大きく変わった場合にそれに適応することができるかどうかは開発エコシステムにかかっているとは思う。
ビットコインは財団にあたる団体が明確に存在しないので少し弱い気はするが、"ビットコイン長者の老人"たちが自身の保有するBTCの価値を高める・維持するためにGrantに相当する寄付を行う経済的インセンティブはあるため、それに期待。
つまり、そんなに価格が上がることはなくて、その分採掘の難易度が下がらないとマイナーの収支が取れなくなるんだが、そんなことしてたらいつか危ないんじゃないか？51%攻撃リスクだっけか。「ビットコインはハッキングされたことがありましぇぇん（ｷﾘｯ」とかいつまで言ってられるだろうね？
マイナーの収支と1ビットコインの当たりの価格に関しては相関がないですね。マイナーの収支はTransaction Feeによって賄われるので、1ビットコインの採掘報酬がゼロになったとしても運用は回る設計になってます。慈善事業ではなくビジネスなので電気代やハードウェア費の採算が取れないTransaction Feeを指定したトランザクションは取り込みませんので、1ビットコインあたりの価値が1億円円だろうが1万円だろうが、Transaction Feeは現実的な値に落ち着くのが経済の原理です。51%攻撃が未来永劫受けないのはありえない話なので、過疎化したら攻撃可能になるのは間違いないです。まぁ過疎化した時点で二束三文だと思いますけど。
究極的には「ビットコインというシステムが提供する価値」「イーサリアムというシステムが提供する価値」の需要がどのくらいあるかが全て。
もし誰も使わなくなったら終わるというのはその通り。
ただし、これはどんなサービスでも同じで、別にWeb3に限った話ではない。
結局そこで流行っているスマートコントラクトは、チンパンホイホイのポンジーファイナンスくらいなんだが。... 規制されない金融を可能にしたら、クソみたいなスキームでクソみたいなマネーゲーム環境が無限に湧いて出てきて、誰が一番多くドルに換金できるかの競争が起こって盛り上がり、なぜかそれがイノベーションとか言われているだけなんだ。規制ないところのアナーキー金融道なんてものは、産業革命の時代以降ずっと人類は経験してて、そのときどきでクソって結論になっててな。そりゃこの世界、規制ばかりでつまらないクソな世界だけど、これでもマシなクソを選んだんだよ。
大前提、投資家保護を完全に無視した無法地帯であるDefiとそこでのマネーゲームはポンジと批判されて然るべき。
その上で第一原理的な発想で「Defiは規制に対応していけば良い」そして「規制に対応したとしても価値がある」と考える。
仮にDefiがしっかりと規制された未来を考えてみると、その金融システムには大きく3つの価値があると思う。
これは金融DXやFintechがやろうとしていること、その理想形であり、彼らは既存システムをボトムアップで改善しているが、それに対してDefiは理想的なシステムをデジタルスクラッチで作ってしまって後から規制に対応させるというトップダウンの方法を取っていると整理できる。
第二に「グローバルに規格が統一されており、オープンでパーミッションレスな金融システム」となる。
SWIFTですら各国のシステムのツギハギであり、非常に複雑なシステムになってしまっているという課題感があると聞くし、国際送金、国際証券決済などが全くの追加コストなくシームレスに行える状態というのは未だ実現されていないと理解している。
さらに、オープンさにより金融システムと接続されているシステムを作成するコストが低くなる。
これは既存金融がOpen API、Open Bankingで目指している方向と同じとも言える。
第三に「分散的に動作しており改ざんできないという特性から監査が楽になる」
仮にボトムアップの金融DXが完成したとしても、それを運営する団体が存在した場合はそこに対するトラストが発生する=運営団体が資産を隠したり、改ざんしたりする可能性を捨てきれないため、分散化した金融システムに比べると監査コストが高くなる。
上記3つの価値により、「ファイナンスのコストが大きく下がる」ことが期待される。
そしてそれによって、これまではファイナンスできなかったような小さな主体でもファイナンスにアクセスすることが出来るようになる。
もちろん規制に対応する上で、システムとしても現状から大きく改善される必要はあると思うので、この未来が確実に来るとは言えないが、この未来を信じて仕事をすることに価値はあると思う。
お待たせしましたどーもDAOだお。あのな、DAOなんてものは、株の代わりにトークンで投票するだけで、別に社会的に新しいことはなんもないんだお。でも惹かれる気持ち分かるんだお。なんかイノベーティブに聞こえるし、ウォレットで投票して手軽にガバナンス参加とか新鮮だし良いよね。たまに空からお金落ちてくるし。ディスコードみたいなカッコいいとこには老人もいないし。リリースするソースコードに投票したり、ワクワクするよね。でも、それ、ブロックチェーンいらなくね？ウォレットなんか使いこなせるやつ世の中にどれくらいいると思ってるの？日本人の6人に1人は偏差値40以下なんだが？ニーモニック？100年早いわ。エアドロ？手元にお金ないけどお金配りおじさんになりたい人のためのアレすか！？。ディスコード？運営企業頼みやん？非中央集権どうしたん？。リリースされるコードの投票？デプロイするエンジニアたちは信用しないといけないやん。数人が結託するだけで、みんなから集めたDAO資金からお金無限ちゅーちゅー列車が出発できちゃうプロジェクトばかりなんだが。DAOなんて、自律もしてなければ、分散もしてない、ただの組織なんだお。なんだろう、雰囲気でweb3するのやめてもらっていいすか？
これも同意見。なんでみんなDiscordでやってるのかマジで謎。情報が分散しすぎてて情報収集辛いんじゃ〜。
DAOに関しては定義の整理をするべきと考える。
まずそのDAOは本当にDAOかどうか、つまりDecentralizedかどうかを考える。
まずプロトコルレイヤーであるL1・L2チェーンはDAOであると言えると思う。
世界中の誰もがNodeを動作させることができ、コンセンサスメカニズムによりDecentralizedに動作しているのは間違いない。
誰でもforkすることができる。
一方でアプリケーションレイヤーのDAOは「リリースされるコードの投票？デプロイするエンジニアたちは信用しないといけないやん。」と批判されている通り、そもそもDecentralizedではない = DAOではないものが多い。
DAOであるためには「分散投票の結果として起こる事象やアクションがフルオンチェーンで分散的に動作している」必要がある。
つまり、機能追加の投票を行い、それをコアチームのエンジニアがDeployしている場合などはDAOとはいえない。
一方で、Decentralizedである=分散投票の結果として起こる事象やアクションがフルオンチェーンで分散的に動作しているものの例としては「tokenの保有者がオンチェーンで投票活動をし、ファンドの資金を投票結果で決まった特定のアドレスに送金するロジックまでがオンチェーンで動作している」ような分散ファンドのアプリケーションなどが挙げられる。
この整理をすると批判記事にあるようなDAOはそもそもDAOではないということになるため、批判に同意である。
更に踏み込んで、本当にDecentralizedなDAOは少しは存在するとして、DAOであることで生み出している価値は何かを考える。
プロトコルレイヤーの場合、Decentralizedであることのメリットは「Assetsの管理を自分以外の誰にもされない」金融システムであることだ。
もし仮に利用者が分散マキシじゃないとしても、(中央集権的な金融システムと比較してUXなどその他の条件が同じとすると) 資産の管理を他人に依存して良いことは1つもないので、これには価値があると言えるだろう。
アプリケーションレイヤーの場合は、アプリによるが上記で例に出した分散ファンドでいうと、投資ファンドを誰か特定の人物または数人のグループに依存せずに分散的に運用できるという価値はあるといえる。
これによってファンドマネージャーが資金を持ち逃げするなどのリスクはなくせるというメリットはある。
それにどれだけの需要があるかは未知数だが、少なくとも無価値ではない。
そしてNFT氏とかブロックチェーンゲーム氏。お前らは金の匂いを消せ。お前らが呼び寄せたどんな陽キャでも明るくできないくらい、界隈が冷めてるの気づかないのか？それに、サ終しても、ブロックチェーン上にあなたの資産は残るとかいう嘘やめろ。お前らはブロックチェーンが無くならないといつから錯覚していたんだ？
サービス終了してもブロックチェーンに記録は残りづづけるので嘘ではない。ブロックチェーンがなくならないとは言ってないので。嘘じゃないけど真実ではないこの言い方は私も好きじゃないが。草コインのチェーンはそのうちひっそりと消えるだろうな。
金の匂いの批判に関しては、まずTokenomicsと相性が悪いゲームもGamefiとして提供されていることが原因だと考える。
ゲームの本質的なユーザーバリューは「プレイする面白さ」であるのに、Gamefi・Tokenomicsを導入することにより、Tokenの値段の上下を気にしなくてはいけない、最悪の場合にはゲームを遊んでいたらなぜか損をするという状態になってしまう。
Tokenにより、ゲームの本質的なバリューが毀損されてしまうのでむしろTokenomicsは入れないほうが良い場合が多い。
一方で、Tokenomicsを入れる相性の良いゲームとしては「そもそも賭博性のある」ゲームがある。
賭博性そのものがゲームの面白さというタイプのゲームであればTokenomicsによって面白さが増すことは考えられる。
ただし、賭博は本来しっかりとした規制があるので、規制と折り合いをつけていく必要はもちろんある。
一方で、Gamefiではない=TokenomicsのないBlockchain Gameもあり、これには可能性があると思う。
それらは「運営が終わっても資産が残る」というここで批判されている価値よりも、Composabilityによるバリューが大きい。
Composabilityとはゲーム同士が連携したり、あるゲームの上に別のゲームを拡張して作ったりすることが、誰でもできるという価値である。
これは既存ゲームの世界で考えてもマインクラフトでも行われているし、オセロというゲームを元にしてソシャゲに拡張したものや、麻雀を拡張したゲームなどが多く作られてきている。
あるゲームのバックエンドのロジックであるスマートコントラクトが誰でもアクセス可能なことで、そのゲームの別のClientを作成したり、別のゲーム性を付け加えたりできるイメージである。
拡張できるものの範囲が広がることでより面白いゲームが生まれる可能性はあると思う。
僅かな流動性の中で買い支えて成り立つトークン価格と、膨れ上がったトークン発行量の掛け算で、ユニコーンな時価総額が成り立っているんだ。その縁で辛うじて立っているおびただしいプロジェクト...
言及なし
付け加えると、海外プロジェクトを中心とするWeb3界隈であたかも画期的な発明のように言われている「Stakingさせることによって売り圧を減らす」というトークノミクス手法は、要は顧客である資産の保有者が資産を売れないようにして流動性=売り圧を減らすことで価格を維持するという運営目線の話で、株式会社でいうと「節税手法」みたいなものと理解している。
プロジェクト運営のハックとしては理解できるが、新たな価値を生んでいるイノベーションでもなんでもなく、声高に言うようなことではないと考えている。
間違っている部分や別の考え方などがあればコメント頂けると大変嬉しいです。
https://twitter.com/Lefty_STJ/status/1606356471670661120
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>公金の流れはブロックチェーンで追えるようにするくらいデジタル庁は頑張れよ— れふてぃ (@Lefty_STJ) December 23, 2022
ツイ主がどのような心持でこのような投稿をしたかはわからないが、おそらく行政が運用上の”瑕疵”で文書やデータを紛失したり、まっとうな手続き抜きに内容が変更されたりしたを出来事を観測して憤っているのだろう。
「改ざんはけしからん！そうだブロックチェーンなら改ざん不可なはずだから、大事なデータはブロックチェーンに載せよう！」という氏の気持ちは良くわかる。
現にブロックチェーンが暗号資産以外のケースに応用が利きそうだと発覚した2010年代中盤は、このように行政の文書管理にブロックチェーンを使えば良いのではないかという話も出ていたほどだ。
ただ現実ブロックチェーンを応用した行政のサービスやシステムはまだ出てきていない。実証実験や小さいサービスでは使っているかもしれないが、このような文書管理のようなコア部分はいまだに従来のシステムに依存している。
これはなぜか？ブロックチェーンが未成熟な技術だからか？確かにそうかもしれない。行政が旧態依然のシステムから変えたがっていないからか？それもあるだろう。
しかし、技術が進歩しブロックチェーンが成熟したとしても、デジタル庁が本気の改革に乗り出したとしてもブロックチェーンを上記のようなケースへの応用は難しいのではないかと俺は考えている。
この考えを少し述べたい。はてなでやる内容か？と自問しつつも、誰かの目にとまれば幸いである。
ブロックチェーンは様々な実装が公開されているが、「パブリックチェーン」と「プライベートチェーン」に大別することができる。
この二つの最大の違いはパーミッションレス型か、パーミッション型かという点である。つまり、誰でもネットワークに参加できるのが前者、任意の機関が認証して初めて入れるのが後者である。
行政の監視という点を考えたら、もちろんパブリックチェーンの方がよさそうに思える。みんなで監視できるからだ。
ただ、パブリックチェーンをこのユースケースにあてはめるには課題がある。
一方、プライベートチェーンではどうか。ここも一筋縄じゃいかない。
構築する動機がない: これが一番悩ましい点かもしれない。つまり、行政は自分たちのデータを改ざんできないと困るのだ。改ざんというと言葉が強いが、ちょっとした修正ぐらいも監視されてるなんて溜まったものではない。自分が不便になりそうなものなんて、法律で強制でもしない限り作らないし使わない。
長々と書いてしまったが、とにかく言いたいのは「行政×ブロックチェーンって良いアイデアじゃね？なんで皆やらないんだろう」とTwitterに書き込む前に一旦想像して欲しいのだ。もう考え尽くされたアイデアなのかもしれないと。自分が画期的アイデアの考案者第一号ではないのかもしれないと。
ブロックチェーン自体は素晴らしい技術だがその応用にはみんな苦労してる段階である。行政への画期的なユースケースも今後出てくるかもしれない。それまで暖かく見守ってくれれば幸いである。
みんなー！セックスだよ☆
つーわけで呪術見ました
0はあらすじは知ってるけどちゃんと読んだことはなく
本編も最初読んだのはメカ丸死んだとこあたりからたまに読みはじめて
これからの世界の話がなかなか始まらないあたりで興味持ちはじめて
シンウルトラマンの予告毎回観るけど本当に5月にやるんすかね？
いじめシーンがあることは知ってたからキツかったらイヤだなーと思ったらあっさりだった
つーか、全然泣くとこじゃないのに乙骨とリカちゃんが通じあってるとこで泣きそうになる
オッサンになったからなのか？昔は恋人が幽霊ってセックスできないから意味ないジャンって感じだったけど、今は心が通じあってるならプラトニックでええやんって…
事前に感想チラッと見たら、序盤はシンジ君だけど後半乙骨と言われてたが
マキさんアクションええなー
小学校のは面白かったけどちょっと唐突な感しあり、しかし尺の問題なので仕方ない
デフォルメも忠実に映像化するのはちょっと引っ掛かったがこっちが慣れてないだけと思われる
というかッス口調のキャラを見るとあさひと鯱山の顔が浮かぶっスやっぱ怖いスね猿の呪いは…
夏油がチラチラ暗躍してる感じ面白い
乳揉みは映倫で禁止スよねやっぱ怖いスね映倫は…でも揉み抜きにしてもエロかった(ニホンヘコサル並感)
禅院家ぶっつぶそーのあたりでその後の根切りシーン思い出して妙な面白さが
マキの血を踏んでも気にしないのは秘書が猿の血を避けてたのと対比スね
猿殺しは思想であって感情でヘイトしてたわけじゃないから素が出たとかですかね？
おにぎり先輩(シャケと聞くとU19の飯田くんを思い出す)の逃げろって呪言じゃね？思たけどそういや乙骨呪い耐性あったからそれなんすかね？
ぐちゃぐちゃにしてやるのあたりはもっとぬるっとした方が好みだけどあそこで乙骨が異常性出してきたら変になるのもわかる
乙骨パンチでふっとぶ夏油すき
その後のナナミンのシーンでアレ黒閃じゃんてなった
ミゲル、パーミッションで足止めしてたと思ったらガッツリ戦闘してて笑った
雑草より健闘しとるやんけ
不殺で加減してたとかもなさそうだし
純愛のとこ、流れは知ってたけど自分生け贄にしてたのは知らなかった
シンエヴァやんけー！
介錯されて死ぬ夏油いいっすねーこの後がアレだから変な面白さがあるのはよくない
個人的な好みでは呪霊してた時のがすきだが
天元編とかミミナナがダイジェストなのは演出としてはあり、ただミミナナが悪堕ち原因なのは知ってないと分かりにくくないか？といらん心配したり(説明がくどくなってもだめだけど)
https://anond.hatelabo.jp/20210617075257
上がってるような基本（元増田に上がってるやつの倍ぐらい）が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク＆デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
これが意図なら
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい？
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
TeamGeek（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。
重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。
逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、（基礎的な部分を）調べながら使うようではエンジニア失格ということ。
基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。
以下に挙げた技術（①⑤⑥は他の言語やフレームワークで代替可能）が身に付いていなければまともな企業に就職することは難しい（もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが）。
経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。
特定の言語やフレームワークの書き方を知っていること自体に意味は無い。
重要なのは、他の言語やフレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。
この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。
基本的な構文や、よく使う標準ライブラリは勿論、高階関数・クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。
言語のみではなく、パッケージ管理、単体テスト、タスクランナー等の周辺ツールの使い方も熟知している必要がある。
また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。
Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、
多くの場合、本番環境やテスト環境はLinuxサーバーであるから、以下のような基本的な概念と使い方を知っておく必要がある。
環境構築、CI、デプロイなどは、現在コンテナを使って行うことが当たり前になっている。
これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。
Flaskは、数あるWebフレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。
フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。
データベースは、就職したらMySQLやPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。
作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。
ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式のドキュメントに従ってPostgreSQLを使用して下さい。
SQLite3はファイルにデータを持てる簡易DBなんだけど、Herokuにデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。（DAOを丸ごと書き換える羽目になる）
参考: https://devcenter.heroku.com/ja/articles/sqlite3
今の時代、フロントエンドをフレームワークなしで作るのはただのバカ。
2021年現在、実用的なフロントエンドのフレームワークはReactとVueしかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。
フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVueを完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。
アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。
高速フーリエ変換のような高度な数学は必要ないが、クイックソートや木構造のような基本的なアルゴリズムは当然、その性質を知っていなければならない。
それらは言語の組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。
また、プログラムを読み書きする際には、そのコードの計算量を見積もれなければならない。
セキュリティは言うまでもなく学ばなければならない。
有名な脆弱性や攻撃手法（XSS・SQLインジェクション・CSRFなど）が何だか理解していて、その対策を実装できなければならない。
各種暗号化技術や署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性は理解する必要がある。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 99 | 15446 | 156.0 | 39 |
| 01 | 49 | 10870 | 221.8 | 63 |
| 02 | 37 | 4377 | 118.3 | 37 |
| 03 | 16 | 1270 | 79.4 | 48.5 |
| 04 | 6 | 906 | 151.0 | 103.5 |
| 05 | 11 | 533 | 48.5 | 22 |
| 06 | 13 | 1811 | 139.3 | 62 |
| 07 | 36 | 3487 | 96.9 | 40 |
| 08 | 64 | 5460 | 85.3 | 36.5 |
| 09 | 115 | 6425 | 55.9 | 34 |
| 10 | 97 | 11206 | 115.5 | 39 |
| 11 | 181 | 15409 | 85.1 | 45 |
| 12 | 198 | 13864 | 70.0 | 35.5 |
| 13 | 230 | 18831 | 81.9 | 45 |
| 14 | 194 | 17212 | 88.7 | 44.5 |
| 15 | 231 | 17620 | 76.3 | 35 |
| 16 | 178 | 10891 | 61.2 | 43.5 |
| 17 | 93 | 7222 | 77.7 | 35 |
| 18 | 151 | 13720 | 90.9 | 35 |
| 19 | 199 | 16415 | 82.5 | 36 |
| 20 | 173 | 13747 | 79.5 | 40 |
| 21 | 173 | 17750 | 102.6 | 40 |
| 22 | 180 | 14739 | 81.9 | 36 |
| 23 | 130 | 11704 | 90.0 | 32 |
| 1日 | 2854 | 250915 | 87.9 | 39 |
ストV(6), ビスマルク(4), ＪＯＫＥＲ(4), パーミッション(3), 220万円(3), 貨幣価値(4), ワークシェアリング(4), 出前館(3), ジョーカー(57), 出雲大社(3), ubereats(3), 台風(24), 配達(10), 受賞(7), 福島(8), 出生率(9), 子供部屋(14), 貧乏(36), 飛ぶ(9), 不自由(19), ヒーロー(11), 展示(10), 芸術(14), ギャル(18), 民主党(12), アート(8), 少子化(17), アスペ(15), 文脈(17), 出産(24), 人口(23), ヘイト(15), ハードル(12), 罵倒(13), そうそう(10)
■1年で離婚した /20191008225958(36), ■ 「被爆最高！放射能最高！」はヘイトではない。 /20191009091749(30), ■いちいち気になる英単語の誤用 /20191008225437(18), ■「カメラを止めるな」って何故あんなに人気出たの？ /20191009114445(13), ■世界はバットマンよりジョーカーを求めてるんですかね？ /20191009025332(13), ■UberEatsで1ヶ月働いたので配達員の立場から見た良い点と悪い点を書いて /20191008185049(13), ■「女版ジョーカーが欲しい」と言い出すフェミたち /20191009015740(11), ■オタク女が婚活の愚痴を書く /20191009151407(9), ■お風呂でおしっこしてるのを嫁に見られた /20191008231025(8), ■日本の同調圧力から子供を逃す方法 /20191009120706(7), ■腐女子ってなんであんなに金あるの？ /20191008124611(7), ■増田でオフ会開催しろよ /20191009185014(7), ■政権交代とかしなくていいだろ /20191009221951(7), ■女からジョーカーが生まれない理由 /20191009204231(6), ■ /20191008105703(6), ■なぜ大根はカレーに入れてもらえないのか /20191008143012(6), (タイトル不明) /20191009172316(6), ■海原雄山「では、教えてくれ。パンティーの”ティー”とは何のことだ」 /20191009162355(6), ■埼玉の教採の結果が出た 筆記試験なんてなかった /20191009144845(6), ■ラブホの割引券 /20191009234226(5), ■ /20191008195335(5), ■同担拒否自己投影というフルコンボ夢女子の愚痴とマナーの話 /20191008210954(5), ■ /20191008221153(5), ■怒るのつかれた /20191009000449(5), ■父から受けた性的行為について10年後に父本人に伝えた /20191009020220(5), ■「トイレ行ってきます！」が言えない新入社員。 /20191009114708(5), ■男のプライドってなんなんだろな /20191009120421(5), ■男向けサービスって何でこんな少ないんだろう？ /20191009135825(5), ■妻が妊娠。夫である増田は禁酒すべき？ /20191009145658(5), ■スパゲッティとパスタ /20191009180317(5), ■anond：20191009015740 /20191009191623(5), ■君がそう言われて怒るのは、それが事実だからでしょ？ /20191009192225(5), ■もやしです。 /20191009193611(5), ■ゴキブリって名前がよくない /20191009223652(5)
6675314(4069)
