「リポジトリ」を含む日記 RSS

はてなキーワード: リポジトリとは

2017-11-22

プログラマー英語

今まで "Fixed an issue which" とか "Fixed an issue that" って書いてたけど、海外ゲームパッチノート見たら "Fixed an issue where" って書いてあった。

issue の関係代名詞って where なの?初めて知りました。ごめんなさい。

regist や datas が存在しないのは知ってたけど(数が多くてもはや業界用語感もあるけど)、issue - where は知らなかった。

Github海外リポジトリを見て勉強してないからこうなっちゃうのかな。申し訳ございません。死にます

2017-10-24

なんで未だに 5.4 なんだよ!

PHP のはなし

ウチでは centos を使うことになってる

今だと centos7 だが、これのデフォルトPHPが 5.4 だ

5.5, 5.6, 7.0, 7.1 とでていて、 7.2 がもうすぐとか言われてるのに、 5.4 だ

5.4 が出たのは 2012 年で公式サポートは 2015 年に終わっている

そんな古いもので、使える機能ももちろん古いのだけだ

新しい機能を使おうとしたらエラーになる

もちろんライブラリフレームワークですら対応してないのが多くて古いものしか使えない

さらには、古いバージョンではバグ脆弱性が見つかってもそもそも PHPバージョン自体サポート切れなので放置される

PHP7 や 5.6 対応バージョンにすれば直っているが 5.4 で動くものだと直されない

centos に 7 系を入れることはできなくはないし、難しくはない

だが、デフォルトバージョンを使うことになっている

聞くところによると、保守OSサポートが切れる頃まではすることになっているものが多く、外部リポジトリや自前ビルドになるとサポートが辛いらしい

今 7.1 にしても、その外部リポジトリはウチの保守期限より早くサポートをやめるのでその後の脆弱性などのパッチ自分でどうにかしないといけなくなる

デフォルトのものなら緊急性があれば 5.4 であろうと OSサポートしているためパッチ対応されるらしい

外部リポジトリサポート終わったらバージョン上げればいいじゃない、って思うけどけっこう動かなくなる部分があるらしい(経験談によると)

プロジェクトが大きくなるとチェックと修正がすごく大変なんだろう、そのためのテストじゃないの?って言いたいけど

自社サービスじゃないしクライアントから人件費取るのが難しいとかあるんだろうな、たぶん

そんなこんなで 5.4 を使うらしい

ライブラリ面で苦があるから、自社製ライブラリも多い

OSSライブラリで何が使えてどれを使ってはいけないか、みたいのはコア部分の開発メンバーには知見が溜まってるらしいが、私はそんな将来に役立たないものより 7 系とか新しいもの知識が欲しい


せめて JavaScript の Babel のようなものがあればなぁ・・・ブラウザは使う側の問題で古いのまでサポート必要だが、サーバサイドは新しいの入れればいいだけなので需要がなくて作られないのだろうなぁ

2017-09-24

anond:20170924204251

(またしょうもない教材のステマに利用されて伸びそうなやつだ)

俺は学生の頃からプログラマとして活動してたけど

自頭の良いハイスペックな連中に自尊心が傷つけられる事があり辛みを感じてるよ。

なるべく早く、一つでも二つでも己のプロジェクトオープンソース世界に置いて

リポジトリメンテしてもらうまでの場所を作りなさい。

そういう居場所を作る気概もなく、技術を追いかけるのが苦痛だってんなら

上流を目指して人間を統率する力を日々磨くしかない。

2017-09-21

Javascript 好きなやつって頭おかしくね

なんであんなプアな言語仕様で頑張ろうと思えるのか

最新と言われるES6, ES7にしたって、他の言語からしたらありえないほどに機能が少ない

こんなクソみたいな言語を書いていたら、エンジニアとしての腕が鈍るのではないかと思うほどにクソい

いまは仕事JSを書いているのだけれど、Rubyだったら、Pythonだったら、KotlinだったらSwiftだったらと思わない日ない

驚くのは、こんなクソみたいな言語なのに、好きな人が多いってこと

ReactNativeだとかflowだとかTypeScriptだとかbabelでtranspileなんじゃとかい記事をみない日がない

それだけ好きモンが多いんだろう

JSというブラウザによって取り残された言語へのキャッチアップに多くの時間を割いてしまったがために、

心理的な負荷がかかって俺はJSが好きなんだこれしかないんだとなってしまっている人が多いんじゃないかとかわいそうに思う

JSマンで他の言語かける人って、他の言語と比べて極端に少ないように思う)

クソみたいな言語のくせにnodeのリポジトリお家騒動みたいなんでしょっちゅう盛り上がってるし

JSなんてなくなりゃあいいと思う

あと、好きなやつらはしょうもない言語だってことを認めろ

俺はJavaが好きだけどJavaがクソみたいな言語だってことは認めている

だが、バカな息子をそれでも愛そうの精神で頑張っている

お前らも、そう思えよ

何がES6ならモダンな感じでかけてチョベリグですねだよ

アホか

2017-09-17

まべーん

repo1.maven.orgのリポジトリインデックスデータを取り込みたいかアップデートボタンを押してねと言われ幾星霜

このインデックスデータとやらは何十MBあるんだ


追記:

あった

nexus-maven-repository-index.gz                   2017-09-10 15:25 397699470    

いちじゅうひゃくせん…、400MBか。この回線じゃ無理だな。ごはんでも食べよう

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-08-21

http://b.hatena.ne.jp/entry/s/note.mu/konpyu/n/nc0d2f49676ba

FacebookgithubリポジトリでPATENTSファイル存在するリポジトリリスト

./360-Capture-SDK/PATENTS

./BridgeIC/PATENTS

./CParser/PATENTS

./DelegatedRecoveryReferenceImplementation/PATENTS

./FBAllocationTracker/PATENTS

./FBFetchedResultsController/PATENTS

./FBRetainCycleDetector/PATENTS

./FBSimulatorControl/PATENTS

./Haxl/PATENTS

./IT-CPE/PATENTS

./KVOController/PATENTS

./MazeBase/PATENTS

./MemNN/PATENTS

./PathPicker/PATENTS

./Shimmer/PATENTS

./SoLoader/PATENTS

./SocketRocket/PATENTS

./Stack-RNN/PATENTS

./ThreatExchange/PATENTS

./Tweaks/PATENTS

./UETorch/PATENTS

./UdpPinger/PATENTS

./WebDriverAgent/PATENTS

./android-jsc/PATENTS

./augmented-traffic-control/PATENTS

./bistro/PATENTS

./chef-cookbooks/PATENTS

./chisel/PATENTS

./componentkit/PATENTS

./conceal/PATENTS

./dataloader/PATENTS

./device-year-class/PATENTS

./dfuse/PATENTS

./draft-js/PATENTS

./ds2/PATENTS

./emitter/PATENTS

./eyescream/PATENTS

./facebook-clang-plugins/PATENTS

./fatal/PATENTS

./fb-adb/PATENTS

./fb-caffe-exts/PATENTS

./fb-util-for-appx/PATENTS

./fb.resnet.torch/PATENTS

./fbcuda/PATENTS

./fbcunn/PATENTS

./fbjs/packages/eslint-config-fbjs-opensource/PATENTS

./fbjs/packages/eslint-config-fbjs/PATENTS

./fbjs/packages/fbjs-css-vars/PATENTS

./fbjs/packages/fbjs-eslint-utils/PATENTS

./fbjs/packages/fbjs/PATENTS

./fbjs/packages/signedsource/PATENTS

./fbkutils/PATENTS

./fblualib/PATENTS

./fbnn/PATENTS

./fboss/PATENTS

./fbpca/PATENTS

./fbpush/PATENTS

./fbshipit/PATENTS

./fbtftp/PATENTS

./fbtorch/PATENTS

./fbtracert/PATENTS

./fixed-data-table/PATENTS

./flow/PATENTS

./flux/PATENTS

./fresco/PATENTS

./gnlpy/PATENTS

./hhvm/hphp/hack/PATENTS

./iTorch/PATENTS

./immutable-js/PATENTS

./infer/PATENTS

./ios-snapshot-test-case/PATENTS

./jest/PATENTS

./jscodeshift/PATENTS

./learningSimpleAlgorithms/PATENTS

./libafdt/PATENTS

./liblogfaf/PATENTS

./litho/PATENTS

./luaffifb/PATENTS

./mcrouter/PATENTS

./mention-bot/PATENTS

./metro-bundler/PATENTS

./mysql-5.6/fbson/PATENTS

./network-connection-class/PATENTS

./nuclide/modules/atom-ide-ui/PATENTS

./nuclide/modules/big-dig-samples/PATENTS

./nuclide/modules/big-dig/PATENTS

./nuclide/modules/nuclide-commons-atom/PATENTS

./nuclide/modules/nuclide-commons-ui/PATENTS

./nuclide/modules/nuclide-commons/PATENTS

./ocpjbod/PATENTS

./openbmc/common/recipes-connectivity/lldp-util/lldp-util/src/PATENTS

./osquery/PATENTS

./planout/PATENTS

./pop/PATENTS

./pose-aligned-deep-networks/PATENTS

./prepack/PATENTS

./prop-types/PATENTS

./proxygen/PATENTS

./puewue-backend/PATENTS

./puewue-frontend/PATENTS

./react-devtools/PATENTS

./react-native-applinks/PATENTS

./react-native/PATENTS

./react-vr/PATENTS

./react-vr/ReactVR/PATENTS

./react-vr/react-vr-cli/PATENTS

./react/PATENTS

./rebound-js/PATENTS

./rebound/PATENTS

./redex/PATENTS

./regenerator/PATENTS

./relay/PATENTS

./remodel/PATENTS

./screenshot-tests-for-android/PATENTS

./shimmer-android/PATENTS

./sparts/PATENTS

./stetho/PATENTS

./thpp/PATENTS

./treadmill/PATENTS

./wangle/PATENTS

./wdt/PATENTS

./xcbuild/PATENTS

./xhp-lib/PATENTS

./yoga/PATENTS

./ztorch/PATENTS

2017-07-27

NASgitリポジトリ化して部下と共同作業したい

部下と共同で報告書を作りたい。

メール添付でワードファイルが送られてくるのが うざい!!

図面グラフプロットプロットされた標本)を編集したい。

標本をいじくりたいわけじゃないけど、グラフのいろいろな審美的属性

編集したい。

文章部分

こっちは例えばMicrosoftWordの履歴機能を使えばいいけど。

図面部分

こっちは、Rstudioで描かせることに取り決めたとして( ^ω^)・・・

変更履歴管理したい。

グラフはこういう風に描いてくれ!!!って口頭で指示するだけでなく

実際にグラフに手を加えたい(介入したい)

データ解析

これを行うときに「〇っていうのがあるけど、このパッケージを使ったら?」って提案したい。

https://anond.hatelabo.jp/20170727085837

NASgitリポジトリ化するのは、技術的には可能

だけど、なぜgitGitHubに興味があるのか、一体何がしたいのか。

なぜNAS単体や、またはDropboxなどではダメなのか。gitだとなぜ解決するのか。

gitに何を期待しているのか、まずそこを考え直してみよう。

NASGITやってみたい

GIT

よく理解してない

GITHUB

するとパブリックになって拙い。

非公開は有料。そんな金ない。

NASGITだと、職場にいるときだけしか作業できなくなることに?

どうすればいいのか?

リモートリポジトリクローンする まで読みました。

リモートリポジトリにプッシュする 〃

マージという作業を行なって他の履歴での変更を取り込むまで自分push拒否され」

文章が分かりにくい

マージ作業により他ユーザーの変更履歴を採り入れれば、自分PUSHは通る」


帰宅前に最新のファイルをMegasyncにコピーして

翌朝出社時に最新のをコピーする?

2017-07-24

https://anond.hatelabo.jp/20170724204528

リポジトリプライベート設定して、適宜リリースする感じでいいんじゃねーの?

コード公開してドヤりたいんだったら SourceForge とか使えばいいんじゃないだろうか。(あっちはsvcだが)

2017-06-14

Golang勉強3日目ぐらいで疑問に思っている事

これは将来Golangに慣れて来た頃に読み返すメモです

学習してから3日目ぐらいだけど連続3日でやったとは言っていない。

学習時間は24時間にも満たないと思う。

モチベーションが上がった時に学習する程度。

公式チュートリアルをやってるけどやった箇所は忘れた。

英語版日本語版があるけど日本語版情報が古くないか不安

まだ半分ぐらいしかやってないけど良チュートリアルだと思う。

他のプログラミング言語と違ってチュートリアルの内容が足りないってこともなさそうだし、Golangチュートリアルだけは繰り返しやったほうが良さそう。

からGolangを学ぶならGoogleリポジトリにあるパッケージ管理depを使うほうが安心する。

まだ公式ツールじゃないけど将来なるかもしれないしならないかもしれない。

Googleのことだからgxuiみたいに更新されなくなる危険もあるよな・・・

でもプロジェクト新規作成するときrails new helloに相当するコマンドがないので不便。

スケルトン生成ツールが別途必要だけどフォルダ作るだけだからbatファイル用意するだけで良さそう。

あとGOPATHの設定もか。今のところは手動でやってるけどそのうちbatファイルにしたい。

Golang自体シンプル言語だと思う。

でもやりたいことができないのがつらい。

Rubyみたいにcursesが標準で使えない。

RubyみたいにTKも標準で使えない。

cursesぐらいは標準で出来て欲しいよ。

から他の言語はいらないのにGolangではそんなことでもライブラリを探してきてインストールしないといけない。

開発環境にはGoglandかVimがいい。

Goglandだとそのままでも十分だけどVim場合vim-goを入れるのが良い。

勉強会に参加するときは軽量ノートを持っていくので動作が軽いVimがいい。

でもryzen搭載ノートが来たらIDEに乗り換えるかもしれない。

コマンドラインツールを作るならGolangが一番簡単

cliってライブラリもあるみたいだけど標準機能flagだけで十分便利。

学習3日目でもflagの使い方は楽勝だった。

今の所もあんまりコマンドラインツールに興味ないので難しいことはしない。

とりあえず2ちゃん質問するのが良さそうだけど過疎だった。

過疎ってことはあんまり人気がない?

まだ質問するぐらい基礎的なもの学習してないけど。

やりたいことをぐぐってコピペしてる程度なのでdeferとかgo funcとかグローバル変数とか基礎的な部分はまだ知らない。

インストールが楽だけどWindows作ったらMacでも動くかは謎。

Mac mini買ってから試したい。

でもMacって高いから多分買わないと思う。

MacハードウェアしかMacOSインストールできないライセンスからWindows PCMacインストールできないかapple嫌い。

初心者だけどMac持ってる奴apple信者キモ杉と言わせてくれ

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

2017-03-19

ファイル隠すのにバージョン管理ソフト良いんじゃないかと思った

gitとか

一番最初ルート部分を別にしてコミットしておいて、別ブランチに変えたら普通気づかれない。

エクスプローラ検索ツールファイル検索しても出てこない。

わざわざリポジトリログまで探すことはないだろうけどたまたま見たときにわかることがないように、大きなリポジトリクローンしてきてそこにいれるとかありかも。

Chromium みたいな大規模ならログ一覧をざっとスクロールしてもまずみつからないはず

ブランチ消して reflog だけに残すという手もありかも。

さらファイルを resources.zip にまとめておいて「圧縮した」みたいなコメントだと一覧の中から目に止まらない気がする。

念のためパスワードもつけておく。

見られたくない人にパソコン使わせたときに、ピンポイントリポジトリをみつけて reflog の中から見られたくないものコミットを見つけてパス付き zip解凍するとかまずないでしょ。

はいっても、そこまでして隠すものも見られる可能性ある人もいないけどね

2017-03-09

Docker盲信してる皆様へ

そもそも便利なのかちゃんと考えてる?

「日々Dockerfileをメンテして開発環境がこんなに楽になります!」

Dockerなので本番とも開発者同士でも同じになります!」

馬鹿じゃねーのかw?

Dockerfileメンテなんて手順書メンテとかシェルスクリプトメンテしてんのと大して変わらねーよw

そのDockerfileから作ったものが本番と同一だなんて保証はねーって気づけボケ

本番と同じものを作りたかったら本番からコンテナ作れよ

なんでビルド始めちゃうの?無駄じゃん馬鹿じゃん

それと「同じDockerfileから作ったものから環境差異はありません」なんて寝言まだ言ってるの?

yumaptリポジトリセキュリティアップデートやらで変化する以上

いつも同じ結果になるわけじゃねーだろが、(バージョンロックする方法はあるけどめんどいだろ)

本番でもコンテナを使ってますってやつら以外無理してDocker使う必要ないんじゃねーか?

お前らが欲しいのは軽いVMであって細切れのコンテナじゃねーだろ?

initを潰して,supervisor入れてプロセス管理して・・・ってどう考えてもお前らが望む世界じゃないんじゃねーか?

流行りのコンテナぽくしたいならLXDやらsystemd-nspawnの方がよっぽど筋がいい

というわけでよく考えなおせ

みんながDocker言ってるから無理やり使うって運用やめろ

2017/04/22 追記

続き書いた

http://anond.hatelabo.jp/20170422000230

2017-02-01

ホワイトリスト形式プロキシ建てるのやめてほしい

大手SE会社作業することになったけどさあ・・・

mavenもnpmもpipもgemdocker hubもつながらないような環境で開発しろとか言われてもムリだよ

CentOS公式リポジトリだけ開けてれば問題ないとか思ってんじゃねーぞ

プロキシ建てるのはいいけど、リストメンテする気がないなら、せめてブラックリスト形式にしてくれよ。仕事できないよ

2017-01-31

【開発】アンテナサイトのジェネレーターを作った

しがないWebエンジニアをしています

今年の1月からチマチマ作っていたアンテナサイトのジェネレータを公開しました

アンテナサイトメーカー

http://antena-mk.com/home

サービス説明

お好みのRSS登録するだけであなただけのアンテナサイトの完成です。

自身広告掲載できるので、お小遣い稼ぎもできます

Google Analyticsコードを使ってアクセス解析もできます

ダッシュボードにて、アクセスランキング、逆アクセスランキングなんかも見ることができます

今後はアクセスに応じて調整するような機能などを追加していく予定です。

使用技術

作ってみた感想


ぜひ使って感想ください!

2017-01-26

とあるFのFなSIer現場

他を知らないからひどいのかひどくないのか分からない。教えて

受託開発だよ編
環境
  • 会議用の長机に2人。仕切りなし、狭い
  • 引き出しは2人で1つ。共用
コンピュータ
開発環境
バージョン管理システム
ソースコード
規約
構成管理

2017-01-24

OSSコミュニティについて思ったこと

この間、某有名なリポジトリメンテナンスモード(新機能追加よりもバグ等の修正を優先にする)に入っていることを知って独り言を書こうと思った。

また、この間メンテナや開発仲間でいろんなリポジトリの現状共有の話があった。

最近、様々なOSSコミュニティ記事を見るようになったのも理由の1つかもしれない。

はじめに私は複数リポジトリメンテナをしており、その目線で書けたらと思う。

私が最初に思ったのは結局、OSSコミュニティというのは社会構成は変わらないなぁと思った。

大きな違う点として、

だと思う。

私がOSS活動するのは、志が他の開発者と同じであり楽しいと思えるから

仕事だとお金を稼ぐためというのは当たり前だし、そのために働いている。

なのでお金を稼ぐためという人もいれば、サービスを使われたいとか、もっと拡大させたいとか様々な意識があると思う。

しかし、OSSコミュニティ活動するのは物を良くしたいという部分が大きくコントリビューターやコミッターがそういう意識活動していると思う。

メンテナが減るのは当たり前で、飽きもあるだろうし家庭の事情とかもあるだろう。

また、別の興味あるプロジェクトコントビュートしたり、自分の開発に専念するといったこともあるだろう。

これは私の中で転職に似ているなって思った。

自分のペースで活動できるのでブラックではない。

OSSコミュニティというのは今の時代、多くの会社普通に使っており、市場の規模は大きいと思う。

しかメンテナの数というのはとても少なく、著名なリポジトリでも2, 3人しかいないというところもある。

みんなが知っている有名なフレームワークツールも内部を見ると、少人数で回しているのが現状である

本当にPull Requestを出してくれる方や、バグRFC等のフィードバックをしてくれる方には感謝している。

そういう方が居てこそ成り立っており、このような体験仕事では得られないと思うので大切にしていきたい。

日本人の方の参入率は自分観測範囲では結構低く、やはり敷居が高いのかなって思った。

一番最初に壁になるのが英語だと私は思う。 実際、私はそうだった。

日本だと、どうしても日本語ドキュメント情報が充実していないと流行らないというのも実際そうだ。

新規の方が参入しやすいように考え直す時期なのかもしれない。

いかコミュニティを拡大させつつ維持していくのかが難しいかというのがメンバと話していて自分の中でわかった気がする。

2016-12-27

活躍しているVimmerを教えるよ

この記事増田Vimアドベントカレンダー2016の27日の記事です。




Vimに興味を持ってるけどtwitterで誰をフォローすべきか分からない・・・

そんな迷える羊たちにデータ提供します。

vim-jp積極的活動している(していた) 人達調査してみました。

vim-jpの3つのリポジトリを見ればだいたい分かります


vim-jp/issuesでは、issue作成数、コメント投稿したissueの数を見ていきます

vimdoc-ja-workingとvital.vimでは、コミットすることが重要リポジトリだと思いますので、コミット数とPR数のみ見ていきましょう。

データは2016/12/27 17:00-19:00の期間にgithubからスクリプトで取得

vim-jp/issues issueを作成した数 (only member)


nameOpen中のissueClosedしたissue
DeaR15
Flast00
Kuniwak00
SKAhack01
Shougo1457
alpaca-tc01
basyura00
bouzuya00
cocopon00
crazymaster43
deris10
deton03
eagletmt03
h-east842
hattya21
haya14busa311
ichizok217
iyuuya00
k-takata845
koron71110
lambdalisue01
mattn39129
nocd525
presuku01
raa012124
rhysd03
ryunix00
saitoha11
splhack15
supermomonga00
syui00
thinca2868
tobynet01
todashuta02
tyru1123
ujihisa11
withgod00
ynkdir616
zchee00
zoncoen00

vim-jp/issues コメント投稿したissueの数 (only member)

nameOpen中のissueClosedしたissue
DeaR316
Flast01
Kuniwak00
SKAhack01
Shougo47168
alpaca-tc03
basyura00
bouzuya00
cocopon00
crazymaster1355
deris42
deton24
eagletmt04
h-east69372
hattya22
haya14busa422
ichizok1652
iyuuya01
k-takata78340
koron136374
lambdalisue02
mattn138489
nocd538
presuku38
raa0121416
rhysd112
ryunix10
saitoha715
splhack26
supermomonga01
syui00
thinca58189
tobynet11
todashuta115
tyru4188
ujihisa615
withgod10
ynkdir48204
zchee10
zoncoen00

vim-jp/vimdoc-ja-working Commitした回数 (all user))

nameコミット
k-takata302
ynkdir294
crazymaster256
koron239
nakinor95
mattn87
thinca64
kashewnuts47
h-east35
tyru29
rhysd24
cougar-b21
rbtnn15
deton14
sgur6
aiya0005
haya14busa5
saitoha3
Milly3
machakann2
norisio2
todashuta2
Shougo2
oshow1
lamsh1
ichizok1
miyakogi1
natnu1
pocke1
shiracha1

vim-jp/vimdoc-ja-working PRした回数 (only member)

nameOpen中のPRClosedしたPR
DeaR00
Flast00
Kuniwak00
SKAhack00
Shougo00
alpaca-tc00
basyura00
bouzuya00
cocopon00
crazymaster05
deris00
deton00
eagletmt00
h-east01
hattya00
haya14busa00
ichizok00
iyuuya00
k-takata04
koron06
lambdalisue00
mattn014
nocd500
presuku00
raa012100
rhysd01
ryunix00
saitoha00
splhack00
supermomonga00
syui00
thinca00
tobynet00
todashuta00
tyru03
ujihisa00
withgod00
ynkdir00
zchee00
zoncoen00

vim-jp/vital.vim Commitした回数 (all user)

nameコミット
thinca721
ujihisa480
tyru414
lambdalisue270
haya14busa145
rhysd118
mattn104
Shougo83
syngan60
rbtnn45
crazymaster43
kamichidu32
aomoriringo31
deris22
cohama10
hattya8
itchyny8
ichizok7
Milly5
raa01215
ryunix5
zoncoen5
aiya0004
kozo22
anekos2
basyura2
kannokanno2
suy1
deton1
koron1
m4i1
nicoder1
pocket78781
gitter-badger1
termoshtt1
alpaca-tc1
firisu1
tacahiroy1
y0za1

vim-jp/vital.vim PRした回数 (only member)

nameOpen中のPRClosedしたPR
DeaR00
Flast00
Kuniwak00
SKAhack00
Shougo05
alpaca-tc01
basyura01
bouzuya00
cocopon00
crazymaster023
deris09
deton01
eagletmt00
h-east00
hattya04
haya14busa023
ichizok06
iyuuya00
k-takata00
koron00
lambdalisue235
mattn17
nocd500
presuku00
raa012106
rhysd013
ryunix03
saitoha00
splhack00
supermomonga00
syui00
thinca154
tobynet00
todashuta00
tyru028
ujihisa011
withgod00
ynkdir00
zchee00
zoncoen02

数字で見ると一目瞭然ですね。

数字裏切りません。

数字が2桁ある人はほぼ活躍しているとみなしてよいでしょう。

綺麗に0が揃っている方々は実力を発揮していないだけなのかもしれません。

評価されるべき人が評価される世の中にしましょう。

2016-12-02

コボラーの嘆き

僕も華麗にGitHubリポジトリコミットしたやつをプッシュしたい

2016-12-01

http://anond.hatelabo.jp/20161129234656

人によって話題にするポイントが違っていつつ、これまでの持論?をここぞとばかりに開陳する人が多くて、長引いている感じですね。

エバンジェリストって名乗るのなら技術的にすごいやつじゃないとだめだろ派

一般論としては一理あるんですが、日本マイクロソフト個別論としては、ちょまどはテクニカルエバンジェリストとしての責務を果たしているようなので、なんとも。

それから一般論として技術力はGitHubだけから判断されるべきかという論点もあるでしょう。個別論としては、ちょまどのGitHubリポジトリにはそんなにすごいコードが置いてあるわけでもないようです。

派生して

エバンジェリスト嫌い派

エバンジェリストという言葉だけで虫唾が走るさぶいぼ出るという人もいます

ちょまど「オタサーの姫」派

オタサーの姫話題になるときと同じで、下の2つのどちらかもしくは両方があります

とにかく「性だ」と言いたい人も見かけました。

なお「女性エンジニアは〇〇であるべき」「そんなべきなどありません、女性かどうかで区別する時点でおかしい」などさらジェンダーな方向に向かう話題も見ました。

ちょまど嫌い派

彼女のこれまでの(主にtwitterでの?)ふるまいを嫌っている人たちというのもいるようです。元彼がどうとか。法務エディションも追加?

技術コミュニティ内にヒエラルキーを作るべきではない派

ケーキとかサイン会とかおかしい」という意見の根っこにこれを置いてる人もいれば、ケーキサイン会コミュニティ内のヒエラルキーとは別でしょ?の人もいますね。

後者についてはMSコミュニティの悪習っていうか悪臭として、MS公式発表すごい、MS中の人すごい、MVPMS表彰されたコミュニティリーダー)の人すごい、みたいな雰囲気を感じ取り、そこを嫌う人もいるようです。

MVPの人がコミュニティアクティブ活動しているのをDisるのはどうなのかなーと思いますが、でもコミュニティリーダーならむしろMVPではない人のトークを盛り立てていくべきなのかもしれませんね。例のスライド出した本人もどうやらMVPとのことで……。

コミュニティ嫌い派

もっと殺伐としてるべきなんだよ。とか、ヒューッ!見ろよやつの筋肉を!とか。

2016-11-11

ggcの件でなんで男が通報したのか

女性エンジニアを集めてた GitHub の ggc リポジトリ炎上してアカウント削除された話

http://d.hatena.ne.jp/shouh/20161107/1478521182

文章を読む限りでは、このリポジトリ第一発見者男性のようで、この人物は件のリストにいた女性友達だったようだ。

何人かGitHub通報した人がいるようだけど、その中に何人か男もいたらしい。

被害にあった女性たちが自分通報するのはまだわかるけど、通報した男たちは、この女性たちのなんなのだろうか。

確かにggcの内容は気持ち悪いし、書いた人もキモいが、通報した人のツイートを見るとなんだか良くわからない正義感に満ちあふれてて、それはそれで気持ち悪かった。

通報したらワンチャンあるのか。

2016-11-08

ggcの件でgithub謝罪してアカウント復活してもらえよとか言ってる奴

あんまり無責任発言しないほうがいいよ

復活させたら第三者による訴訟が待っている

それと、スパムと疑われて凍結された場合ならアカウントの復活はできるけど、今回のケースはまっとうな理由で凍結されたわけよ。無理に決まってるでしょう。

後、アカウント凍結経験あるから知ってるんだけど、あれはアカウント凍結されただけでアカウント削除されたわけではないので勘違いしないでもらいたい。

他人からあいつのページ見ても404になるけど、本人は自分リポジトリを閲覧できる。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん