[重要] 利用規約全面改訂のお知らせ
いつもSkebをご利用いただき、誠にありがとうございます。 Skebでは2023年9月1日正午より、利用規約を全面的に改訂させていただきます。 現在の利用規約は2018年11月のサービス公開当時からほとんど変わっておらず、法改正やSkebの機能拡充の度に、継ぎ足しや部分的な変更を加えてまいりました。 Skebはサービス公開当時、単一のイラストのみを取引できるサービスであったため、現在も利用規約は単一のイラストを想定していた条文となっており、各種ガイドラインとの齟齬も年々大きくなっておりました。 また、2023年だけでも、個人情報保護法、特定商取引法、消費者契約法、電気通信事業法、消費税法(インボイス制度)と、Skebに影響を与える改正法の施行が多数あり、現在の利用規約に追記することでは法令への対応が難しくなってまいりました。 さらに、生成AIの台頭や不正利用の増加に伴い、利用規約に禁止事項
【1月23日追記】12月23日、24日に発生しました障害に関するご報告
いつもSkebをご利用いただき、誠にありがとうございます。 12月23日12時よりskeb.jpにアクセスできない大規模な障害が発生しておりましたが、12月24日07時に復旧いたしました。 12月23日、および12月24日が納品期限のリクエストは納品期限を12月25日23時59分までに延長させていただきます。 みなさまには多大なご迷惑をお掛けしましたことをお詫び申し上げます。 本障害につきまして詳細をご報告させていただきます。 概要日時: 12月23日12時22分〜12月24日7時00分 (JST) ダウンタイム: 18時間38分 内容: skeb.jpにアクセスできない不具合 原因: SkebはすべてのサーバとシステムをHerokuに設置していたが、障害発生時刻より同サービスのアカウントが理由の通知なく利用できなくなった。 解決: Herokuの一切の利用を中止し、すべてのサーバとシステ
Elasticsearch マッピング
Elasticsearch におけるマッピングとは、リレーショナルDBでいうところのテーブル定義に相当します。しかし、単にデータを格納する為のフィールドを用意して型を設定するだけではありません。Elasticsearch では、フィールドの型の他に言語解析処理などのドキュメントを検索可能にする為の各種設定が可能です。 スキーマーレスが一つの特徴の Elasticsearch では、ドキュメントをインデックスすると自動的に各フィールド毎にフィールドタイプなどのマッピングが自動で設定されインデックスが作成されます。また、事前にマッピングを設定可能な仕組みとなっています。 自動マッピングまずは以下の内容で、インデックスを作成し自動マッピングについて見て行きます。 ブログ記事毎に１つのドキュメントをインデックス各ドキュメントはドキュメントタイプ story にインデックスドキュメントタイプ sto
Elasticsearch 日本語で全文検索 その１
日本語は、分かち書きしない言語のため日本語でちゃんと全文検索できるようにする為には、検索対象のコンテンツの内容、利用するユーザーのスキルなどを考慮しなければ検索精度を向上させることは非常に困難です。逆を言えば、検索対象のコンテンツ、利用するユーザーのスキルが変われば設計が変わってくると言えます。 日本語を検索できるようにトークナイズするには、代表的なものに形態素解析とN-グラムがあります。簡単に説明すると形態素解析を検索で使用すると、単語単位で検索するため、適合率が高く（マッチ度が高いものが検索される）、再現率が低くなります（検索漏れが多くなる）。例えば、キーワード ”京都” では、”東京都” はヒットしません。一方、N-グラムを検索で使用すると、データベースのLike検索に近い検索が可能になり、形態素解析とは逆に、再現率が高くなり、適合率が低くなります。 これらの日本語解析の特徴と、検索
Elasticsearch 日本語で全文検索 その２
Elasticsearch では、すでに日本語で全文検索する為のトークナイザーやノーマライズなどの加工処理で使用するフィルターなどがビルトインまたは、サードパーティ製のプラグインとして多数存在します。 ここでは、日本語全文検索で使用しそうなトークナイザーやフィルターなどを説明します。 主要モジュールNGram Tokenizer N-グラムを提供するトークナイザーです。Elasticsearch にバンドルされています。Japanese (kuromoji) Analysis for Elasticsearch 日本語形態素解析を提供するプラグインです。各種 Analyzer、Tokenizer、TokenFilterが含まれます。cjk_width Token Filter 半角・全角などを統一するためのフィルターです。Elasticsearch にバンドルされています。Lowercas
「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を１年掛けて整理した
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
「謎水事件」日本システム企画社のNMRパイプテクター問題
株式会社日本システム企画（以下、日本システム企画社）が販売している商品で、マンションなど集合住宅において水道管に外側から「NMRパイプテクター」と名付けられた装置を取り付けると、管の中の赤錆が黒錆に変わるため配管設備を更新しなくても数十年保たせることができる、という通称「謎水装置」と言われる機器が販売されています。 そもそも仕組みが良く分からないので、私たちのような大規模タワーマンションの管理組合などでは「そのような機序が不明な装置を入れるべきではない」という判断も働くのですが、老朽化が進み、管理組合や住民に科学リテラシーがない人たちが多いと「少しでも配管保守工事が先延ばしにできるなら」とこの機器を採用してしまう物件があるということで、問題になっていました。 単に、科学的根拠が分からない製品がそれなりの高額で売られているという案件であるというだけでも大変なことなのかなと思います。しかしなが
Docker 19.03新機能 (root権限不要化、GPU対応強化、CLIプラグイン…)
NTTの須田です。2019年7月23日に公開された、Docker 19.03の新機能をお伝えします。2018年11月8日にリリースされたDocker 18.09以来、8ヶ月ぶりのリリースです。 root権限不要化従来のDockerは、ホストのroot権限でデーモン(dockerd)を動作させる必要があったため、脆弱性や設定ミスを突かれると、ホストのroot権限を奪われる恐れがありました。 Docker 19.03では、非rootユーザでデーモンを実行できるようになりました(Rootlessモード)。 Rootlessモードを有効化することで、万一Dockerに脆弱性や設定ミスがあっても、攻撃者にホストのroot権限を奪取されることを防ぐことが出来ます。ただし、現時点ではcgroupを利用できないなどの制約があります。 RootlessモードのDockerは， curl -fsSL http
We are Google employees. Google must drop Dragonfly.
We are Google employees. Google must drop Dragonfly. We are Google employees and we join Amnesty International in calling on Google to cancel project Dragonfly, Google’s effort to create a censored search engine for the Chinese market that enables state surveillance. We are among thousands of employees who have raised our voices for months. International human rights organizations and investigativ
3週間で48,000行のコードをこの世から抹消した話 – FiNC Engineering Blog – Medium
qsona (twitter) です。以前、7,600行のコードを安全にこの世から抹消した話 という記事を投稿しましたが、今回はそれよりもずっと泥臭い話を書きたいと思います。あまりテクニカルな話はありませんが、現場における取り組み・試行錯誤の経過を読んでいただければ幸いです。 たくさん消しました、がんばりました〜背景肥大化するRailsサービスFiNCはマイクロサービスを指向しており、主にRuby on Railsで書かれたサービスが30個ほど存在します。しかし、FiNCアプリのメインとなるRailsのサービスは、テーブル数800を超える大きなサービスになっています。 FiNCのサービスは2014年から書きはじめており、かなり初期の段階(2015年)からマイクロサービス化を意識してきました。にもかかわらず1つのサービスが肥大化している理由はいくつかあります。 最初の1〜2年ですでに大量のコ
ドキュメントを残さない
普段仕事をしてるとき、いろいろなことに気を使いながら仕事をしてると思う。たとえばissueには、その背景、やりたいことや期待する効果、制限事項、認識している副作用やリスクの情報等などを書くような運用ルールを作っているチームは多いらしい。しかし、私たちのチームではそういうルールはない。それでうまくいくんだっけっていう話をよく質問されるので、考えてみた。 コードの品質をカバーするためのコメント私たちは、常にわかりやすいコードを書けるとは限らない。解説として、コメントが役立つ場面はある。 ちょっと待ってよ「よし、Why notを書こう！」と言って上手く書けるのは、そうとうに経験を積んだ人だ。そして、経験を積んだ人は大体問題ない。悪いコードほどコメントが必要だが、良いコメントが書けるくらいならコードはもっと良くなってる。鶏と卵じゃん。 コメントについて議論する暇があったら、コードについて議論したほ
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
オライリーから「仕事ではじめる機械学習」が出版されます
どういう本なの？まえがきのスクリーンショットを貼りましたが、この本は多くの機械学習の本とは異なり、機械学習の実務で使えるようになるために知りたい、機械学習を含めたシステムのアーキテクチャや機械学習プロジェクトの進め方、効果検証をどうするのかということをまとめました。 めざすところのイメージ既に多く刊行されているTensorFlowやChainerでディープラーニングをしてみようというものでもなければ、機械学習の理論をわかりやすく解説するといった類のものでもありません。ゼロから作るDeep LearningやCourseraのMachine Learningで学んだけど、実際の仕事に活かすにはどうしたら良いだろう？という疑問に答えているつもりです。また、大学の講義などで機械学習は学んだけど、実際仕事で機械学習のプロジェクトを進めるときはどうすればいいんだろう？という人にも得るものがあると思い
MBPからThinkpad X1 Carbon(2017)に移行した
joker1007さんも煽っていることもあり、MacBook Pro Retina(2015) 15インチが重すぎてしんどいので、Thinkpad X1 Carbon(2017)を買いました。2.04kgから1.13kgへと大幅軽量化しました。外での打ち合わせや出張も結構増えてきて、Macは電源も含めると辛い重さになるので思いきって買いました。背中と腰が死にそうなので軽さは正義です。(msfmさん色々ご相談に乗っていただきありがとうございました！） 選定のポイントは 1.3kg以下英語キーボードメモリ16GB15万円くらいまでという条件で選んだのですが、最後まで残ったのはDell XPS13とX1 Carbonだけでした。最初は値段の安さと軽さに惹かれてZenbook 3をメインに機能と値段の比較表を書いていたんですが、途中で店頭でキーボード触ってみて、日本語キーボードだとホームポジション
「やってみないとわからない」という思考停止
「やってみないとわからない」だから、試すんだ。そのことは間違いじゃない。確かにその通り。 立派な計画を立てても実行しなければ、1ミリも社会に影響を与えない。 頭でっかちにならずトライアンドエラーで、逐次修正しながら進めよう。 アジャイルにやっていきましょう。少しずつ小さく試していけば大丈夫。 そう、世の中には、やってみないとわからないことばかりだ。正解が決まっていないことの方が多い。 だから、やってみる、行動してみるということに価値はある。 ・・・だけど、それ、本当にやってみないとわからないことなのか？と考えたか。「やってみないとわからない」といって、考えてみることも放棄してないか。 考え尽くしたあとに、やってみないとわからないことを試さないと、やってみたことが良かったかどうかもわからない。 やってみることに仮説があるかどうか。 なぜやるのか。仮説をもって取り組めば、仮説が正しかったか、間
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rethinking Database Migrations: The Diminishing Role of the down() Method in PHP Frameworks
Unlock the Power of Dynamic Features in Symfony: The Ultimate Guide to implement Feature Flags
The Rise and Fall of Ruby on Rails
Pinia, The New (and better) State Management System For Vue
The Mistakes I Made As a Beginner Programmer
