Figmaで作ったデザインをWebサイトに即反映「STUDIO」 | 進化が止まらない！ 最新ツール
ChatGPT使い方総まとめ - Qiita
こんにちは！sakasegawaです！ ( https://twitter.com/gyakuse ) 今日は今流行のChatGPTについて紹介します！ ChatGPTとは OpenAIが開発するGPT-3(※)というめちゃくちゃすごい言語モデルをベースとしたチャットアプリです。 色んな質問にすぐ答えてくれます。 この記事ではさまざまな使い方を紹介します。 https://chat.openai.com/ ちなみにGPT-3関連では、noteの以下記事も便利なのでぜひ読んでみてください AIがコミットメッセージ自動生成！神ツール『auto-commit』『commit-autosuggestions』の紹介 ※正確にはGPT-3.5シリーズと呼ばれています ChatGPTの仕組みを考えながらプロンプトを作る手法はこちらに別途まとめています 文章 質問-応答 〜について教えて Wikiped
コードを1行追加するだけでどんなWebサイトもノーコードで編集できる「Scepter」を使ってみた！ - paiza times
どうも、まさとらん（@0310lan）です！ 今回は、WebサイトのHTML内に1行のコードを追加するだけで、誰でもノーコードでカスタマイズができるようになるWebサービスをご紹介します！ Webサイトの要素を直接クリックしてそのまま編集ができるようになるので、誰でも簡単にカスタマイズができるうえ、好きな要素を追加してまったく異なるページを作成してしまうことも可能です。 Webサイトのカスタマイズやノーコード開発にご興味ある方は、ぜひ参考にしてみてください！ 【 Scepter 】 ■「Scepter」の使い方 それでは、「Scepter」をどのように使えばいいのか詳しく見ていきましょう！ まず最初にトップページ上部にある【Sign up for Free】ボタンをクリックして無料のユーザー登録を済ませておきます。 ユーザー名・メールアドレス・パスワードを入力すれば登録完了です！ 次に「S
データ分析者たちのコードレビュー #とは - 散らかったJupyter notebookを片付けるかどうするか問題を考える - JX通信社エンジニアブログ
JX通信社シニアエンジニアの@shinyorkeです. 最近はチームの朝会でよく着ているTシャツにツッコミを受けてます.*1 JX通信社では, いい感じにデータを整備・運用しているデータ基盤を駆使して, BI（Business Intelligence）文脈でのデータ分析・可視化. ダッシュボード作ったり. 機械学習的なアプローチを使ったR&Dと機能開発（分類タスクなど） といった業務・タスクを社員・インターン問わず行っています. データ分析でSQLを書いたり, 「新しいアルゴリズム試すやで！」的なノリでPythonのコードをゴリゴリ書く・動かして結果を見て振り返ってまた臨む...って楽しいですよね. チームの皆さんも, もちろん私もモチベーション高くやってるわけですが！？ あれ, notebookどこ行ったんや...🤔 よくありますよねー（震え） 自分もチームメイトも, 前のめりになっ
機械学習によく使うPythonのコード一覧まとめ | AI入門ブログ
AI機械学習を用いた経営問題の解決や幅広い業種へ多数のコンサルティングの経験を持つ。AIプロジェクトに関するコンサルティングだけではなく、AI人材の育成、会社全体のDX化など幅広い分野で活躍中。AIに関わる講演を多数行なっている。 今回は機械学習でよく使うPythonのプログラムコードをアルゴリズム別に紹介していきます。 そして、機械学習といえばScikit-Learn。Scikit-Learnでよく使うコードを紹介します。 最後におまけとして、PandasやNumpyでよく使うプログラムコードも紹介します。 これらのプログラムコードはコピペで利用できるのでブックマークしておくことをおすすめします！ これからエンジニアを目指して機械学習のPythonを学びたい方、エンジニア入門としてプログラムコードを書きたい方はこの記事を参考にしてください。
Puppeteerで不要なCSSを消す - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。フロントエンドエキスパートチームの穴井（@pirosikick）です。福岡在住で、普段は福岡のweworkで働いています。他のメンバーは皆、東京に居てリモートで仕事をしていますが、モブでわいわい開発していますし、weworkが快適すぎて、毎日楽しいです！ フロントエンドエキスパートチームでは、サイボウズの各プロダクトが抱えるWebフロントエンドの課題を解決するのが仕事の一つです。 blog.cybozu.io 最近の取り組みとして、Puppeteerで不要なCSSを消した事例を紹介します。 このブログは、6/19に福岡で開催した「Google I/O '19のWebをまとめる会」で登壇したときの内容を詳細に説明しつつ、アップデートした部分もあるので、発表見たぞ、スライド見たぞという方も見ていただけますと幸いです。 speakerdeck.com きっかけ とあるプロダクトのCS
【更新】7pay問題でオムニ7アプリのソースコードに漏洩の疑い。｢GitHub｣上で誰でも入手可能だったか
7payをめぐる脆弱性の懸念が解決しないまま、不正使用事件発覚から約3週間が経った。この間、実行犯とみられる複数の中国籍の容疑者が逮捕され、また外部ID連携の実装の不備から、セキュリティーの懸念を指摘する報道が続いている。 セブン&アイHDは7月中を目処に、今後の対応策などを公表する予定だ。 しかしここへきて、これまでとは異なる、別の問題が浮上してきた。 7payにも関連する、ECアプリ｢オムニ7｣の設計図にあたるソースコードが漏洩していた可能性がある。オムニ7アプリはセブン-イレブンアプリとは別アプリだが、ログインまわりの設計は非常に似通っているとみる専門家もいる。 事実であれば、アプリ開発の管理体制、アプリ自体やサービスのセキュリティーに関するリスクの有無についても、一層の警戒が必要になる可能性がある。
ソフトウェア設計の言語化スキルを磨くこと｜qsona
たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く
もうPythonの細かい書き方で議論しない。blackで自動フォーマットしよう - Make組ブログ
「ここで改行するほうがキレイで良いと思います」 『いや、私はこちらのほうがキレイ良いと思います』 コードレビューでこういう議論をしたことはありませんか？ 大切なことだとは思いますが、生産性にはあまり直結しません。議論を避けるために書き方を決めるほうが良いでしょう （個々の問題について逐次議論するのがエネルギーを無駄にしてしまいます。一度決めて、再利用するようにしたいものです）。 今日はそのために使える black というツールを紹介します （「私はflake8を使ってるから結構です」と思われるかもしれませんが、少し違う話なので読んでみてください）。 blackを使おう Pythonのコードを自動でフォーマットしてくれる black を紹介します。 github.com blackはPythonのコードフォーマッターで、自動的にPythonプログラムの書き方を修正してくれます。 PEP8 と
ソースコードを分析し、コードの構造や階層・依存関係を可視化する便利な無料ツール -Code Crumbs
フローチャート ※依存関係・フローチャートはJavaScriptのみです。 対応言語は、下記の通り。 JavaScript TypeScript Python PHP Java C++ 望む言語が他にあればIssueにどうぞ、とのことです。 Code Crumbsのデモ デモでは、JavaScriptのコードでその動作を確認できます。 デモページ 依存関係はDependenciesをオンに、フローチャートはFlowChartタブをクリックします。 Code Crumbsの使い方 セットアップ codecrumbをインストールします（yarn global add codecrumbs）。 codecrumbs -d project-src-dir -e project-src-dir/index.jsを実行し、プロジェクトに合わせてパラメータを変更します。-dはソースコードを含むディレクト
Pull Requestに動作確認方法を書け - 橋本商会
ある程度アプリケーションの規模が大きくなってくると、ある変更がどこまでの影響範囲だと思っているのかがコミュニケーションにおいて重要
ロギングにおける十戒 | Yakst
どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。アプリケーションのログを拡張する手助けとなるのがこの「十戒」だ。 新年の私のブログにようこそ。監視とログのモニタリングについてのParisのdevopsメーリングリストでのスレッドに返信を書いた後、長らく心に留めていたブログ記事を思い出した。 このブログ記事は、私のOpsとしての顔をもって、主に開発者向けに書いた。 どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。多くの場合、これは予言をするのと同じようなことだからだ。トラブルシューティング中にどんな情報が必要かを知るのはとても難しい。それが、Opsエンジニアの大きな助けとなるよう、あなたのアプリケーションのログを拡張する手助けとなるこの「十戒」を望んだ理由だ。 1. 自分でログを書くべ
20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog
こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに本番リリースしました。 「それってテストいるんですか？」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi
無理をしないコードレビュー - クックパッド開発者ブログ
会員事業部の三吉（@sankichi92）です。 クックパッドでは、GitHub Enterprise の Pull Request を使ったコードレビューを広く実施しています。 この記事では、私がコードレビューすることに対する苦手意識をなくすために意識したことを紹介します。 クックパッドでは、テックリードや新卒、インターン、バイトといった肩書きに関係なく、誰もがレビュワー・レビュイーになります。 チームやプロダクトによって開発ルールは少しずつ異なりますが、私の所属する会員事業部では、PR を出したときに GHE やチャットで部内のエンジニアにメンションして、その時にレビューできる人がレビューするという形を取っています。 私は、昨年2017年に新卒入社したのですが、それまでは個人開発や研究用のコードしか書いたことがなく、短期インターンシップを除くチーム開発の経験がありませんでした。 配属当
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 - エンジニアHub｜Webエンジニアのキャリアを考える！
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 Rubyコミッター・園田裕貴（Yugui）さんが、長年の経験で体得したソースコードに書くべき「コメントの技法」を教えてくれました。 プログラミングにおいて、どんな初心者でも書けるけれど、適切に書くのは上級者でないと難しいもの。それがコメント（=ソースコードに書かれている注釈やメモ）です。 不適切なコメントをつけても、プログラムの動作には影響しません。しかし、書き方の巧拙によって、コードの可読性や理解のしやすさには雲泥の差が出ます。良質なコメントが良質なコードをつくるのです。 今回はRubyコミッターでありgrpc-gatewayの開発者でもあるSupership株式会社の園田裕貴（Yugui）さんに、優れたエンジニアがどんな観点を持ち、どんなコメントを書いているのかを聞きました。 園田 裕貴（そのだ・
コメントのいらないプログラムの書き方｜NZ MoyaSystem
パラメータを決める 次に関数に渡すパラメータを決めます。 関数の名前で表現されている処理を実現するには、どれだけのパラメータがあればよいか？ と考えてみましょう。 今回の例でいえば「お客さんの年齢」と「日付」があれば、すべてのチケット価格が計算できます。 ということで、age と date の2つのパラメータを渡すことにします。 function calculateTicketPrice (age, date) { } パラメータの名前も、なにを表しているかわかるようにしてくださいね。 くれぐれも「hensu」とか適当な名前をつけたり、同じ変数にぜんぜん違う値を繰り返し代入したりすることのないようにしましょう。 テストを書く 次にユニットテストを書きましょう。 テストは常に更新される仕様書です。 業務ロジックをテストに説明させておけば、関数の仕様をコメントにいちいち書く必要などありません。
ソースコードの形状ルール | 吉本式BEM設計（BEM設計ベース）
HTMLのソースコードの形状ルール 今回のこの記事に対しての反響について 日頃から他の実装者が制作したWebサイトのソースコードを見るようにしていますが、美しいソースコードだと思えるソースコードにはなかなか出会えません。 「美しいソースコード」という意味には、単に「美しい」だけではなく「見やすい」という意味も含めて使用しています。 タイトなスケジュールに追われて、ソースコードを整える余裕がないというのが現状でしょうか。 中でも最も気になるのが、インデントです。 Webサイトのソースコードを見ると8割程度の割合で、インデントが付いています。 なぜインデントを付けるのかを聞くと「コーディングミスが防ぎやすい」「作業効率が良くなる」という回答がきます。 これについて否定はしませんが、ではインデントを付けないとコーディングミスが起きやすく、作業効率が悪いのかというと、そんなことはありません。 私は
プロジェクト全体のコードの行数からいい感じかどうか知りたい - mattak's blog
数年前のプロジェクトで100行未満のファイルをプロジェクト全体の95%にする。 という趣意でメンテしやすさを確保しようとした。 (テストやコードジェネレートしたものは除いて計測するような指標) speakerdeck.com これはわりと簡便で良い指標だと個人的に感じている. どんなプログラミング言語やアーキテクチャでもすぐに適用でき、ある程度プロジェクトの健康状態がそこからわかるからだ。 この話をすると、クラス感の依存関係をみたり、コミットログでの編集頻度などより複雑な解析しようと試みる人がいる. それはそれでとても良いのだけど、個人的にはこの指標の柔軟さ、簡便さ、費用対効果の高さが気に入っている. ファイル行数の分布グラフがばらついているプロジェクトは、だいたい何か設計や機能が失敗している. 昔どこかの勉強会で、行数が多いほどエンバグする可能性が高まるという当たり前の事実を聞いた。 実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / #tamarubykaigi01
プログラムのコードには、個人を識別できる“指紋”が残されている：研究結果