「E+」を含む日記 RSS

はてなキーワード: E+とは

次の25件>

2019-01-31

■e+に登録した

SMS認証はまあいいんだけど認証コード取得のために登録したらすごい勢いで電話がかかってくる

おそらく音声ガイダンスなのだろうけどその電話番号で検索するとアダルトサイト請求とか出てくる

認証コード自体はショートメッセージで別の番号からくるのでユーザ的にその電話は必要なく

ユーザ体験としては「e+でSMS認証したら秒でアダルトの詐欺？から電話がかかってくる」

もしかして登録ページ自体が巧妙な偽物で水飲み場＋フィッシング詐欺なのかな？と思ってしまったしそれを疑い始めると何を信じていいかわからなくなる

Googleで電話番号を検索すると1番上に「ワンクリック アダルトサイト請求（詐欺」と出てくるのでガセならe+は訂正なり何かの措置をとったほうがいいのでは？

Permalink | 記事への反応(0) | 20:01

2019-01-24

■anond:20190124105003

node+typescript+react「何故私を無視する！」

Permalink | 記事への反応(1) | 10:51

2019-01-03

■anond:20190103184241

// WindowsProject7.cpp: アプリケーションのエントリ ポイントを定義します。
//

#include "stdafx.h"
#include "WindowsProject7.h"

#define MAX_LOADSTRING 100

// グローバル変数:
HINSTANCE hInst;                                // 現在のインターフェイス
WCHAR szTitle[MAX_LOADSTRING];                  // タイトル バーのテキスト
WCHAR szWindowClass[MAX_LOADSTRING];            // メイン ウィンドウ クラス名

// このコード モジュールに含まれる関数の宣言を転送します:
//ATOM                MyRegisterClass(HINSTANCE hInstance);
BOOL                InitInstance(HINSTANCE, int);
LRESULT CALLBACK    WndProc(HWND, UINT, WPARAM, LPARAM);
INT_PTR CALLBACK    About(HWND, UINT, WPARAM, LPARAM);

#include <list>

class MyWindow;
	
std::list< MyWindow *> windows;

class MyWindow
{
public:

	HWND hWnd;



	MyWindow()
		:hWnd(NULL)
	{
		windows.push_back(this);
	}

	virtual ~MyWindow()
	{
		std::list< MyWindow *>::iterator it;
		for (it = windows.begin(); it != windows.end(); it++)
		{
			if (*it == this)
			{
				windows.erase(it);
				break;
			}
		}
	}

	static MyWindow * find(HWND key)
	{
		std::list< MyWindow *>::iterator it;
		for (it = windows.begin(); it != windows.end(); it++)
		{
			MyWindow *target = *it;

			if (target->hWnd == key)
			{
				return target;
			}

		}

		return NULL;
	}



	//
	//  関数: MyRegisterClass()
	//
	//  目的: ウィンドウ クラスを登録します。
	//
	ATOM MyRegisterClass(HINSTANCE hInstance)
	{
		WNDCLASSEXW wcex;

		wcex.cbSize = sizeof(WNDCLASSEX);

		wcex.style = CS_HREDRAW | CS_VREDRAW;
		wcex.lpfnWndProc = WndProc;
		wcex.cbClsExtra = 0;
		wcex.cbWndExtra = 0;
		wcex.hInstance = hInstance;
		wcex.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_WINDOWSPROJECT7));
		wcex.hCursor = LoadCursor(nullptr, IDC_ARROW);
		wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
		wcex.lpszMenuName = MAKEINTRESOURCEW(IDC_WINDOWSPROJECT7);
		wcex.lpszClassName = szWindowClass;
		wcex.hIconSm = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

		return RegisterClassExW(&wcex);
	}

	//
	//   関数: InitInstance(HINSTANCE, int)
	//
	//   目的: インスタンス ハンドルを保存して、メイン ウィンドウを作成します。
	//
	//   コメント:
	//
	//        この関数で、グローバル変数でインスタンス ハンドルを保存し、
	//        メイン プログラム ウィンドウを作成および表示します。
	//

	int blocks[100][100];

	BOOL InitInstance()
	{
		hInst = hInstance; // グローバル変数にインスタンス処理を格納します。

		ATOM c = MyRegisterClass(hInstance);
		x = 0;
		y = 0;
		boxType = 0;

		hWnd = CreateWindowW(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
			CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, nullptr, nullptr, hInstance, nullptr);

		for(int x = 0 ; x < 100 ; x++)
		{
			for (int y = 0; y < 100; y++)
			{
				blocks[y][x] = 0;
			}
		}

		if (!hWnd)
		{
			return FALSE;
		}

		return TRUE;
	}

	BOOL ShowWindow()
	{
		BOOL ret;
		ret = ::ShowWindow(hWnd, SW_SHOW);
		::UpdateWindow(hWnd);

		return ret;
	}


	HINSTANCE hInstance;
	MSG msg;
	BOOL run;
	int x;
	int y;
	BOOL Main()
	{

		HACCEL hAccelTable = LoadAccelerators(hInstance, MAKEINTRESOURCE(IDC_WINDOWSPROJECT7));
		run = true;
		int rc;
		// メイン メッセージ ループ:
		while (run)
		{
			DWORD obj = MsgWaitForMultipleObjectsEx(0, NULL,  100 , QS_PAINT| QS_ALLEVENTS,0);
			if (obj <= WAIT_OBJECT_0)
			{
				while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
				{
					if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
					{
						TranslateMessage(&msg);
						DispatchMessage(&msg);
					}
					if (msg.message == WM_QUIT) {
						run = FALSE;
					}
					if (msg.message == WM_CLOSE) {
						run = FALSE;
					}

				}
			}
			else if (obj == WAIT_TIMEOUT)
			{
				y++;
				PAINTSTRUCT ps;
				HDC hdc = BeginPaint(hWnd, &ps);
				this->OnPaint(ps);
				EndPaint(hWnd, &ps);
				::UpdateWindow(hWnd);
				RECT Rect2 = { 0,0,48*9,48 * 100 };
				InvalidateRect(hWnd, &Rect2, TRUE);
			}
			else if (obj == WAIT_FAILED)
			{
				rc = GetLastError();
			}
			else {

			}
		}


		return TRUE;

	}

	int boxType;

	BOOL WriteBoxOLDBox()
	{
		int width = 24;

		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB(48, 48, 48));
		for (int y = 0; y < 30; y++)
		{
			for (int x = 0; x < 8; x++)
			{
				if (blocks[y][x] == 0)
				{
					continue;
				}

				RECT Rect = { 0,0,48,48 };
				BOOL ret;

				Rect.left = width * x + 1;
				Rect.right = width * (x + 1) - 1;
				Rect.top = width * y + 1;
				Rect.bottom = width * (y + 1) - 1;

				ret = FillRect(hdc, &Rect, hBrush);


			}
		}

		DeleteObject(hBrush);

		return FALSE;
	}


	BOOL WriteBox()
	{
		WriteBoxOLDBox();

		switch (boxType)
		{
		case 0:
			return WriteBoxI();
		case 1:
			return WriteBoxL();
		case 2:
			return WriteBoxZ();

		}

		return TRUE;
	}

	BOOL WriteBoxZ()
	{
		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB(48, 48, 246));

		int width = 24;

		RECT Rect = { 0,0,48,48 };
		BOOL ret;

		Rect.left = width * x + 1;
		Rect.right = width * (x + 1) - 1;
		Rect.top = width * y + 1;
		Rect.bottom = width * (y + 1) - 1;

		ret = FillRect(hdc, &Rect, hBrush);


		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.left += width;
		Rect.right += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);


		DeleteObject(hBrush);

		return TRUE;
	}


	BOOL WriteBoxL()
	{
		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB(48, 246 , 48));

		int width = 24;

		RECT Rect = { 0,0,48,48 };
		BOOL ret;

		Rect.left = width * x + 1;
		Rect.right = width * (x + 1) -1 ;
		Rect.top = width * y + 1;
		Rect.bottom = width * (y + 1) -1;

		ret = FillRect(hdc, &Rect, hBrush);


		Rect.top    += width; 
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.left   += width;
		Rect.right  += width;
		ret = FillRect(hdc, &Rect, hBrush);

		DeleteObject(hBrush);

		return TRUE;
	}

	BOOL WriteBoxI()
	{
		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB( 246 , 48 , 48));

		int width = 24;

		RECT Rect = { 0,0,48,48 };
		BOOL ret;

		Rect.left = width * x + 1;
		Rect.right = width * (x + 1) - 1;
		Rect.top = width * y + 1;
		Rect.bottom = width * (y + 1) - 1;

		ret = FillRect(hdc, &Rect, hBrush);


		//Rect.left   += width;
		//Rect.right  += width;
		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		DeleteObject(hBrush);

		return TRUE;
	}

	BOOL SaveBoxI()
	{
		blocks[y  ][x] = 1;
		blocks[y+1][x] = 1;
		blocks[y+2][x] = 1;
		blocks[y+3][x] = 1;
		return TRUE;
	}


	BOOL OnPaint(PAINTSTRUCT &ps)
	{
		if (x > 8) {
			x = 0;
		}
		if (x <0) {
			x = 8;
		}
		if (y > 20) {
			switch (boxType)
			{
			case 0:
				SaveBoxI();
				break;
			case 1:
				break;
			case 2:
				break;
			}

			y = 0;
			boxType++;
			if (boxType > 2)
			{
				boxType = 0;
			}
		}

		this->WriteBox();

		return TRUE;
	}



	BOOL OnKey(WPARAM wParam)
	{
		if (wParam == VK_LEFT)
		{
			x++;
		}
		if (wParam == VK_RIGHT)
		{
			x--;
		}
		return TRUE;
	}


};


int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
                     _In_opt_ HINSTANCE hPrevInstance,
                     _In_ LPWSTR    lpCmdLine,
                     _In_ int       nCmdShow)
{
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);

    // TODO: ここにコードを挿入してください。

    // グローバル文字列を初期化しています。
    LoadStringW(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
    LoadStringW(hInstance, IDC_WINDOWSPROJECT7, szWindowClass, MAX_LOADSTRING);
    //MyRegisterClass(hInstance);



	MyWindow win;



	win.hInstance = hInstance;

	// アプリケーションの初期化を実行します:
	if (!win.InitInstance())
	{
		return FALSE;
	}

	BOOL ret;

	win.ShowWindow();

	ret = win.Main();

	if (ret)
	{
		return 0;
	}else {
		return (int)win.msg.wParam;
	}



}






//
//  関数: WndProc(HWND, UINT, WPARAM, LPARAM)
//
//  目的:    メイン ウィンドウのメッセージを処理します。
//
//  WM_COMMAND  - アプリケーション メニューの処理
//  WM_PAINT    - メイン ウィンドウの描画
//  WM_DESTROY  - 中止メッセージを表示して戻る
//
//
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
    case WM_COMMAND:
        {
            int wmId = LOWORD(wParam);
            // 選択されたメニューの解析:
            switch (wmId)
            {
            case IDM_ABOUT:
                DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About);
                break;
            case IDM_EXIT:
                DestroyWindow(hWnd);
                break;
            default:
                return DefWindowProc(hWnd, message, wParam, lParam);
            }
        }
		break;
	case WM_KEYDOWN:
		{
			MyWindow *target = MyWindow::find(hWnd);
			target->OnKey(wParam);
		}
	break;
    case WM_PAINT:
        {
            PAINTSTRUCT ps;
            HDC hdc = BeginPaint(hWnd, &ps);

			MyWindow *target = MyWindow::find(hWnd);
			target->OnPaint(ps);


            // TODO: HDC を使用する描画コードをここに追加してください...
            EndPaint(hWnd, &ps);
        }
        break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default:
        return DefWindowProc(hWnd, message, wParam, lParam);
    }
    return 0;
}

// バージョン情報ボックスのメッセージ ハンドラーです。
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    UNREFERENCED_PARAMETER(lParam);
    switch (message)
    {
    case WM_INITDIALOG:
        return (INT_PTR)TRUE;

    case WM_COMMAND:
        if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
        {
            EndDialog(hDlg, LOWORD(wParam));
            return (INT_PTR)TRUE;
        }
        break;
    }
    return (INT_PTR)FALSE;
}

Permalink | 記事への反応(1) | 19:31

■anond:20190103170543

テトリス風

落ちてくるブロックの描き方

わかりやすく関数化してみた

まずはブロックの種類は３種類

　

WriteBoxLとWriteBoxIとWriteBoxZ

の違いをよく見比べて

自力で違いがわかれば

プログラマーにはなれるとおもう

とはいえ、コレを自力でわかるならもっと儲かる仕事あるとはおもうけどな

　

	BOOL WriteBox()
	{
		switch (boxType)
		{
		case 0:
			return WriteBoxI();
		case 1:
			return WriteBoxL();
		case 2:
			return WriteBoxZ();

		}
	}

// WindowsProject7.cpp: アプリケーションのエントリ ポイントを定義します。
//

#include "stdafx.h"
#include "WindowsProject7.h"

#define MAX_LOADSTRING 100

// グローバル変数:
HINSTANCE hInst;                                // 現在のインターフェイス
WCHAR szTitle[MAX_LOADSTRING];                  // タイトル バーのテキスト
WCHAR szWindowClass[MAX_LOADSTRING];            // メイン ウィンドウ クラス名

// このコード モジュールに含まれる関数の宣言を転送します:
//ATOM                MyRegisterClass(HINSTANCE hInstance);
BOOL                InitInstance(HINSTANCE, int);
LRESULT CALLBACK    WndProc(HWND, UINT, WPARAM, LPARAM);
INT_PTR CALLBACK    About(HWND, UINT, WPARAM, LPARAM);

#include <list>

class MyWindow;
	
std::list< MyWindow *> windows;

class MyWindow
{
public:

	HWND hWnd;



	MyWindow()
		:hWnd(NULL)
	{
		windows.push_back(this);
	}

	virtual ~MyWindow()
	{
		std::list< MyWindow *>::iterator it;
		for (it = windows.begin(); it != windows.end(); it++)
		{
			if (*it == this)
			{
				windows.erase(it);
				break;
			}
		}
	}

	static MyWindow * find(HWND key)
	{
		std::list< MyWindow *>::iterator it;
		for (it = windows.begin(); it != windows.end(); it++)
		{
			MyWindow *target = *it;

			if (target->hWnd == key)
			{
				return target;
			}

		}

		return NULL;
	}



	//
	//  関数: MyRegisterClass()
	//
	//  目的: ウィンドウ クラスを登録します。
	//
	ATOM MyRegisterClass(HINSTANCE hInstance)
	{
		WNDCLASSEXW wcex;

		wcex.cbSize = sizeof(WNDCLASSEX);

		wcex.style = CS_HREDRAW | CS_VREDRAW;
		wcex.lpfnWndProc = WndProc;
		wcex.cbClsExtra = 0;
		wcex.cbWndExtra = 0;
		wcex.hInstance = hInstance;
		wcex.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_WINDOWSPROJECT7));
		wcex.hCursor = LoadCursor(nullptr, IDC_ARROW);
		wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
		wcex.lpszMenuName = MAKEINTRESOURCEW(IDC_WINDOWSPROJECT7);
		wcex.lpszClassName = szWindowClass;
		wcex.hIconSm = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

		return RegisterClassExW(&wcex);
	}

	//
	//   関数: InitInstance(HINSTANCE, int)
	//
	//   目的: インスタンス ハンドルを保存して、メイン ウィンドウを作成します。
	//
	//   コメント:
	//
	//        この関数で、グローバル変数でインスタンス ハンドルを保存し、
	//        メイン プログラム ウィンドウを作成および表示します。
	//
	BOOL InitInstance()
	{
		hInst = hInstance; // グローバル変数にインスタンス処理を格納します。

		ATOM c = MyRegisterClass(hInstance);
		x = 0;
		y = 0;
		boxType = 0;

		hWnd = CreateWindowW(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
			CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, nullptr, nullptr, hInstance, nullptr);

		if (!hWnd)
		{
			return FALSE;
		}

		return TRUE;
	}

	BOOL ShowWindow()
	{
		BOOL ret;
		ret = ::ShowWindow(hWnd, SW_SHOW);
		::UpdateWindow(hWnd);

		return ret;
	}


	HINSTANCE hInstance;
	MSG msg;
	BOOL run;
	int x;
	int y;
	BOOL Main()
	{

		HACCEL hAccelTable = LoadAccelerators(hInstance, MAKEINTRESOURCE(IDC_WINDOWSPROJECT7));
		run = true;
		int rc;
		// メイン メッセージ ループ:
		while (run)
		{
			DWORD obj = MsgWaitForMultipleObjectsEx(0, NULL,  100 , QS_PAINT| QS_ALLEVENTS,0);
			if (obj <= WAIT_OBJECT_0)
			{
				while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
				{
					if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
					{
						TranslateMessage(&msg);
						DispatchMessage(&msg);
					}
					if (msg.message == WM_QUIT) {
						run = FALSE;
					}
					if (msg.message == WM_CLOSE) {
						run = FALSE;
					}

				}
			}
			else if (obj == WAIT_TIMEOUT)
			{
				y++;
				PAINTSTRUCT ps;
				HDC hdc = BeginPaint(hWnd, &ps);
				this->OnPaint(ps);
				EndPaint(hWnd, &ps);
				::UpdateWindow(hWnd);
				RECT Rect2 = { 0,0,48*9,48 * 8 };
				InvalidateRect(hWnd, &Rect2, TRUE);
			}
			else if (obj == WAIT_FAILED)
			{
				rc = GetLastError();
			}
			else {

			}
		}


		return TRUE;

	}

	int boxType;

	BOOL WriteBox()
	{
		switch (boxType)
		{
		case 0:
			return WriteBoxI();
		case 1:
			return WriteBoxL();
		case 2:
			return WriteBoxZ();

		}
	}

	BOOL WriteBoxZ()
	{
		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB(48, 48, 246));

		int width = 24;

		RECT Rect = { 0,0,48,48 };
		BOOL ret;

		Rect.left = width * x + 1;
		Rect.right = width * (x + 1) - 1;
		Rect.top = width * y + 1;
		Rect.bottom = width * (y + 1) - 1;

		ret = FillRect(hdc, &Rect, hBrush);


		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.left += width;
		Rect.right += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);


		DeleteObject(hBrush);

		return TRUE;
	}


	BOOL WriteBoxL()
	{
		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB(48, 48, 246));

		int width = 24;

		RECT Rect = { 0,0,48,48 };
		BOOL ret;

		Rect.left = width * x + 1;
		Rect.right = width * (x + 1) -1 ;
		Rect.top = width * y + 1;
		Rect.bottom = width * (y + 1) -1;

		ret = FillRect(hdc, &Rect, hBrush);


		Rect.top    += width; 
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.left   += width;
		Rect.right  += width;
		ret = FillRect(hdc, &Rect, hBrush);

		DeleteObject(hBrush);

		return TRUE;
	}

	BOOL WriteBoxI()
	{
		HDC hdc = GetDC(hWnd);
		HBRUSH hBrush = CreateSolidBrush(RGB(48, 48, 246));

		int width = 24;

		RECT Rect = { 0,0,48,48 };
		BOOL ret;

		Rect.left = width * x + 1;
		Rect.right = width * (x + 1) - 1;
		Rect.top = width * y + 1;
		Rect.bottom = width * (y + 1) - 1;

		ret = FillRect(hdc, &Rect, hBrush);


		//Rect.left   += width;
		//Rect.right  += width;
		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		Rect.top += width;
		Rect.bottom += width;
		ret = FillRect(hdc, &Rect, hBrush);

		DeleteObject(hBrush);

		return TRUE;
	}


	BOOL OnPaint(PAINTSTRUCT &ps)
	{
		if (x > 8) {
			x = 0;
		}
		if (x <0) {
			x = 8;
		}
		if (y > 8) {
			y = 0;
			boxType++;
			if (boxType > 2)
			{
				boxType = 0;
			}
		}

		this->WriteBox();

		return TRUE;
	}



	BOOL OnKey()
	{
		x++;
		return TRUE;
	}


};


int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
                     _In_opt_ HINSTANCE hPrevInstance,
                     _In_ LPWSTR    lpCmdLine,
                     _In_ int       nCmdShow)
{
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);

    // TODO: ここにコードを挿入してください。

    // グローバル文字列を初期化しています。
    LoadStringW(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
    LoadStringW(hInstance, IDC_WINDOWSPROJECT7, szWindowClass, MAX_LOADSTRING);
    //MyRegisterClass(hInstance);



	MyWindow win;



	win.hInstance = hInstance;

	// アプリケーションの初期化を実行します:
	if (!win.InitInstance())
	{
		return FALSE;
	}

	BOOL ret;

	win.ShowWindow();

	ret = win.Main();

	if (ret)
	{
		return 0;
	}else {
		return (int)win.msg.wParam;
	}



}






//
//  関数: WndProc(HWND, UINT, WPARAM, LPARAM)
//
//  目的:    メイン ウィンドウのメッセージを処理します。
//
//  WM_COMMAND  - アプリケーション メニューの処理
//  WM_PAINT    - メイン ウィンドウの描画
//  WM_DESTROY  - 中止メッセージを表示して戻る
//
//
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
    case WM_COMMAND:
        {
            int wmId = LOWORD(wParam);
            // 選択されたメニューの解析:
            switch (wmId)
            {
            case IDM_ABOUT:
                DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About);
                break;
            case IDM_EXIT:
                DestroyWindow(hWnd);
                break;
            default:
                return DefWindowProc(hWnd, message, wParam, lParam);
            }
        }
		break;
	case WM_KEYDOWN:
		{
			MyWindow *target = MyWindow::find(hWnd);
			target->OnKey();
		}
	break;
    case WM_PAINT:
        {
            PAINTSTRUCT ps;
            HDC hdc = BeginPaint(hWnd, &ps);

			MyWindow *target = MyWindow::find(hWnd);
			target->OnPaint(ps);


            // TODO: HDC を使用する描画コードをここに追加してください...
            EndPaint(hWnd, &ps);
        }
        break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default:
        return DefWindowProc(hWnd, message, wParam, lParam);
    }
    return 0;
}

// バージョン情報ボックスのメッセージ ハンドラーです。
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    UNREFERENCED_PARAMETER(lParam);
    switch (message)
    {
    case WM_INITDIALOG:
        return (INT_PTR)TRUE;

    case WM_COMMAND:
        if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
        {
            EndDialog(hDlg, LOWORD(wParam));
            return (INT_PTR)TRUE;
        }
        break;
    }
    return (INT_PTR)FALSE;
}

Permalink | 記事への反応(1) | 18:42

2018-12-23

■anond:20181223182722

一気に並べてみる

オーソドックスな書きかた

int i;
int space;
for (int i = 0; i < 8; i++)
{
	for (space = 0; space < i; space++)
	{
		printf(" ");
	}
	printf("Hello world\n");

}

すまん　<は半角の＜に置き換えてくれ（ｗ）

バッファをつかってループを１つ削る

	int i;
	int space;
	char buffer[8];
	char buffer2[8];
	memset(buffer, 0, 8);
	memset(buffer2, 0, 8);
	for (int i = 0; i < 8; i++)
	{
		memset(buffer, 0x20, i);
		printf("%sHello world\n",buffer);

	}

memsetも削ってみる

	int i;
	int space;
	char buffer[8];
	char buffer2[8];
	memset(buffer, 0, 8);
	memset(buffer2, 0, 8);
	for (int i = 0; i < 8; i++)
	{
		buffer[i] = 0x20;
		printf("%sHello world\n",buffer);

	}

この場合は特に影響はないが一般的にはmemsetを使う使わないは大きな影響になるので

memsetを削る場合は注意が必要

C++を使ってみる

	std::string space;
	for (int i = 0; i < 8; i++) {
		printf("%sHello world\n", space.c_str());
		space += " ";
	}

C++を使ってみるの別回答

	std::string space_org;
	for (int i = 0; i < 8; i++) {
		std::string space = space_org + " ";
		printf("%sHello world\n", space.c_str());
		space_org = space;
	}

考察

ざつにかんがえても　書き方いろいろ　

それぞれメリット　デメリットが有る

つまり　まぁ　どれがいいというよりは

状況に応じてかき分けていく必要がある

学校の授業などだと

アルゴリズムの話で

ヒープソート　マージソート　クイックソートの比較みたいな話があるけど

そこまで難しい話にいかなくても

ハローワールドだけ見てかつ雑に考えてもこのぐらいは

書き方がたくさんある

どれを書くか？どれがいいか？　考えると面白い

Permalink | 記事への反応(2) | 18:32

■anond:20181223150830

３つともおなじ

int i;
int space;
for (int i = 0; i < 8; i++)
{
	for (space = 0; space < i; space++)
	{
		printf(" ");
	}
	printf("Hello world\n");

}

すまん　<は半角の＜に置き換えてくれ（ｗ）

	int i;
	int space;
	char buffer[8];
	char buffer2[8];
	memset(buffer, 0, 8);
	memset(buffer2, 0, 8);
	for (int i = 0; i < 8; i++)
	{
		memset(buffer, 0x20, i);
		printf("%sHello world\n",buffer);

	}

	int i;
	int space;
	char buffer[8];
	char buffer2[8];
	memset(buffer, 0, 8);
	memset(buffer2, 0, 8);
	for (int i = 0; i < 8; i++)
	{
		buffer[i] = 0x20;
		printf("%sHello world\n",buffer);

	}

書き直すごとにアルゴリズムがちょっとづつ良くなったり悪くなったり

どれがすき？

Permalink | 記事への反応(1) | 15:25

■

int i;
int space;
for (int i = 0; i < 8; i++)
{
	for (space = 0; space < i; space++)
	{
		printf(" ");
	}
	printf("Hello world\n");

}

すまん　<は半角の＜に置き換えてくれ（ｗ）

====

Hello world
 Hello world
  Hello world
   Hello world
    Hello world
     Hello world
      Hello world
       Hello world

Permalink | 記事への反応(1) | 15:02

2018-12-10

■anond:20181210113445

俺はワークブーツちゃん！

川底のワークブーツこういうのならそんなに違和感ない。

問題は「楽にはける」という当初の目的から逸脱してること...

Permalink | 記事への反応(0) | 11:37

2018-10-16

■anond:20181016154609

知らんけど、Apple Care+に入ってる前提として、インシデント代は全額過失者負担でも別におかしくないんちゃうかな。（8000円くらい）

壊れる可能性がある中でApple Careに入ってないのなら全額弁償はナシで折半位やろうけど。

Permalink | 記事への反応(1) | 15:49

2018-09-26

■プロデューサーよ、お前らの愛は結局金か？

どうも、元アイマスPです。

元、というのは私はもうすでにPを引退したからです。

現状アプリの類は消去しました。

グッズの類が大量に残っていますが、まぁいずれ処分するでしょう。

今回このブログを書こうと思ったのは、私のとある胸糞悪い経験を吐き出しておきたかったのと、これを見たPさん、あるいはアイドルマスターに限らず、いわゆる課金系アプリゲームをプレイしてる全ての人に表題の内容を問いかけたいからです。

課金ゲームにおける「愛」は結局課金でしか測れないのか？という事

アイマス風の言い方をすれば

プロデューサーの「担当愛」は結局課金額でしか測れないのか？

という事です。

事の発端は2年前、私がサークルの先輩からアイドルマスターを勧められた事に始まります。

私はどちらかというとオタク系コンテンツはそれなりに嗜んでいたのでアイマスもすぐにはまり、のめり込んでいきました。

アニマスから入り、劇場版で気になった後輩の子達を見てミリオンライブを始め、シンデレラガールズ、SideMと次々にどハマりしていきました。

改めて説明するまでもないと思いますが、アイマスにはゲームとライブがあります。ゲーム内のガシャを回し、イベントを走って担当のSRカードをゲットする。ライブで声優さんのパフォーマンスを見て感動して「アイマス最高」と唱える(笑)まぁそんな感じで各々楽しんでると思います。

コンテンツを応援するにはいろんな方法があります。ゲームに課金する、ライブに参加する、グッズを買う、二次創作をしてみる。

楽しみ方は本来人それぞれであり、それぞれがそれぞれの形で趣味を謳歌しています。

私の楽しみ方は基本的にライブに参加する事でした。

アイマスにハマった当初、私はまだ学生でした。

学生のアルバイトでは月々稼げる金額はどんなに頑張ってもたかが知れています。

どんなに頑張っても、社会人が月々稼げる金額になど到底及ばない事は想像に難くないでしょう。

アイマスを含めいわゆるソーシャルゲームには「天井」が設けられていることが多いです。

ガシャなどで「この金額までつぎ込めば必ず目当てのカードが手に入りますよ。」というボーダーラインだ。

ゲームにもよるがアイマスは大体ソシャゲの方は5万くらい、音ゲーアプリの方だと10万程度だろうか。

5万10万など学生にとってはかなりの大金である。

それ以上を稼ぎ出せたりお小遣いをもらっていたりと状況は様々だがこの金額を毎月叩き出せる人は全国でもそんなにいないだろう。

さらにイベントでランキング上位に到達するためにも上記レベルの課金はある程度必須と言っていい。

私は各コンテンツ(当時3つ)毎に「担当(他のコンテンツで言うところの「推し」)が複数人いた。

一人がイベントないしガシャで来たら5〜10万ぶっ飛ぶのである。

しかもそれが複数人いると言うことは数ヶ月に一回レベルでその出費、ましてやイベントが重なろうものなら倍プッシュである。

どんなにバイトを増やして掛け持ちしても追いつけるものではない。

そもそもバイトを増やしたら肝心の学業遊び就活諸々に支障が出る。

でも、担当の事は本当に好きだから何かしらの形で応援したい。

なので私はライブを中心に応援することを選んだ。

ライブなら事前に日程が設定されているのでそれに向けて貯金ができる。

ライブを通じて金銭面でも、気持ち的にも担当やコンテンツを応援できる。

そう思っていた。

だが、アイマスを布教してくれた先輩(仮にN氏としよう)は違った。

彼は社会人である。しかもどうやらそこそこ良い仕事をしていると見られる。

毎月のように一定数の金額を彼の担当のガシャやイベントに費やし、コンスタントに入賞していたところを見ると間違いない。

彼はいわゆる「ライブ勢」が大嫌いで、「声優のライブを見て何が面白いんだ」

「こいつらがライブにつぎ込んだ金を直接課金すれば良い話だ」

「こいつらは声優オタとしては一流だがアイマスPとしては三流」

などと事あるごとにこき下ろしていた。

まぁ、いわゆる「在宅」というやつである。

彼はサークルのOBでオタク仲間の中の中心的な存在だったため、同期後輩もなかなか彼に意見する事は難しかった。

それを知ってか知らずか、彼はその集まりの中で二言目には「プロデューサーの流儀」を語りたがり、「コンテンツに課金できない奴は三流のにわか」という定説を偉そうに唱えていた。

私はミリオンライブが初めて触れたアイマスだったため、イベントの走り方など分からず、中途半端な課金額で爆死するということを繰り返していた。

といっても前述した通り、学生にとっての大金を定期的にぶち込めるなんて暴挙ができるわけがないので突然イベントが告知されて担当が上位報酬に来てさぁ走れと言われたって走れるわけがない。

突然の出費もある、月々のいろんな支払いがある。それを社会人と比べれば微々たるお金の中で工面してるのだ。趣味であるゲームに対する優先順位なんて、お察しである。

それでもなんとか工面したお金をつぎ込んだところで結果は散々たるものだった。それを知ったN先輩は事あるごとに

「お前の担当愛はその程度なのか？」

「中途半端な事しかできなくて担当に申し訳ないと思わないのか？」

「おい爆死野郎w」

とバカにしてきた。

自分は担当が本当に好きだったからそれなりに調べてるし、イベントも出来る限り追ってるし、二次創作を出してみたりもした。何よりライブは担当が出演すると分かれば必ずCDを積んだり、e+に殴りこんだり、最悪友達を頼ってでも必ず参加した。極力現地で。

それなのに爆死したら担当を名乗る資格がないのだろうか？

ゲームに課金できなかったら担当としてダメなのか？

そんな漠然とした疑問が胸の内を占めていた。

だが、所詮趣味だし、好きでやっている事だからと気に留めていなかった。

今年の3月、あの日が来るまでは。

大学を卒業した私はサークルの追い出しコンパ(追いコン)に参加した。

1年生から4年生まで数十人という大規模な追いコンで、サークルで顔を合わせるけど名前は知らない後輩も数多くいた。

N先輩も参加していた。

追いコン事態は順調に進み、最後に4年生が一人ずつ挨拶をするときに事件は起きた。

自分の番になった時にN先輩が

「よっ！三流クソにわかP！」

「爆死野郎！」

と大声で叫んでいたのだ。

みんなに聞こえる声で

流石に私も堪忍袋の緒が切れた。

いくらなんでも後輩が何十人もいる前でそんなこと言わなくても良いじゃないか

これでは卒業間際の最後の最後で飛んだ赤っ恥である。

その時は笑って流したが、後日、新歓のミーティングに顔を出していたN先輩に詰め寄り、あの時の発言の意味を説明し、訂正して欲しい。本気で恥ずかしかったんだからみんなの前で謝罪してほしいと訴えた。

すると、彼の隣にいた別の先輩(A先輩とする)が顔を真っ赤にして怒り、怒鳴り散らし始めたのだ。

彼の主張を要約すると以下の通りである。

・先輩に向かってその態度はなんだ。

・大勢の前で生意気な態度を取ったお前もNの事を貶めている。お前にNを断罪する資格などない。お互い様だ。

・そもそもアイマスにおいて何を持って担当とするかなんて人それぞれで明確な基準などない。お前の主義主張を押し付けるな。

私はとても惨めな気持ちになった。

私はただ、あの時の発言を取り消して欲しかっただけで、せめてみんなの前で謝って欲しかっただけなのに…

これではただの公開処刑ではないか。

するとA先輩の怒りっぷりを見たN先輩はへらへらと笑いながらA先輩をなだめ、以下のような主張を始めた。

・酒の勢いで言っただけだ、気にするな。

・お前が○○(私の担当)をいかに愛してるのかはみんながよく知っている。

・なのにも関わらずイベントの走り方が下手くそだから私はそれをいじってるだけ

・自分は昔ライブ専門でゲームに全く金を落とさない同期に「お前はだから三流なんだ」と言われたことが本当に悔しかった。お前にそうなって欲しくないからああやって言ってあげてたんだ。

彼の口から、最後まで「後輩数十人の前で私の名誉を貶めた事に関する謝罪の言葉」はありませんでした。

これを期に私はアイマスから遠のきました。百年の恋も冷める瞬間とはこの事なのでしょう。

アイマスPは課金額で他人にマウントを取り合うような人間しかいないんだなぁ

こんなデータがクラッシュしたら吹っ飛ぶ画像にうん万円も賭けなきゃ担当名乗る資格がないのが、Pの常識なんだなと察してしまいました。

ここまでの話を聞いて

「別にこの先輩がおかしいだけ。」

「増田が考えすぎ気にしすぎ。」と思う人が大半なのではないかと思います。

ですが、私がこの件について許せないのはそこだけではないのです。

私の担当は 田中琴葉でした。

そう、中の人である種田梨沙さんが昨年活動を休止されて、ミリシタでの実装が大幅に遅れた、あの田中琴葉です。

私は、声優さんの不在によって琴葉の存在がだんだん希薄になっていく事をずっと悩んでいました。

4th Liveでも現地で感じた「琴葉が置いていかれてるのではないかという不安」にずっと悩まされていました。(最後のThank youでそれが解消され、安心から大泣きしてしまいましたが笑)

ちょうど就職活動中だった事もあり、イベントになかなか課金ができず、どうすれば琴葉を応援できるのか、どうしたらミリシタから入ったPさんに琴葉がここにいると示すことができるのか、ずっと悩んで、苦しんで、精神をかなり病みましたがそれでも2月に琴葉がミリシタに実装されてやっとこれからなんだと思いました。

自分も就職が決まり、やっとこれから琴葉にたんまりお金を使ってあげられる、本気でプロデュースできると思っていました。

その思いを、悩み抜いた思いの全てを、N先輩はみんなの前で汚い足で踏みにじったのです。「課金額が少ない」「ゲームに投資してない」たったそれだけの理由で。

もう一度言いますが、わたしはライブを中心にお金を落としています。

ライブだけに費やした金額なら数十万に上るでしょう。

でも、それ以外に一切お金をかけていないということではありません。そんなこと有り得ません。

グッズも買ってるしCDだって全て新品で揃えたし肝心のゲームにだって課金してます。

学生時代はイベント時に1,2万が限度でしたがそれでも担当が来たら必ず走って回すようにしてます。

それでも足りないのでしょうか。

担当が取れなかったらその時点でP失格なのでしょうか。

私はあの日大勢の前で3流にわかと罵られないといけなかったのでしょうか。

もう全てがバカバカしくなってしまいました。

5thは一応参加しました、最高でした。

でももう自分のアイマス人生はこれで終わりだなと思いました。

あんな辱めに公開処刑まで受けては大学の後輩や同期に顔向けできないからです。

いまだにガシャやイベントが来るたびにN先輩の言葉が、あの日の恥ずかしさ惨めさが胸をよぎって、まっすぐアイマスを愛することができないからです。

もうすでに周囲には引退を伝えました。

N先輩はいずれ勝ち誇った顔で「やっぱりあいつはその程度だったかw」と話すことでしょう。

画像データ音声データにうん万もぶち込んで一生イキってろバカ。

Permalink | 記事への反応(21) | 14:53

2018-09-25

■anond:20180925190549

今PHPと言えばLaravel１強だけれど、単にJson返すだけのwebapi作るだけならNode+Expressの方が楽なんだよな。

コード的にはほぼ一行だったりするし。

時代の流れはあったにせよ、何故ここまでPHPが流行ってしまったのかは謎。

Permalink | 記事への反応(2) | 19:13

■anond:20180925144857

DBpediaで適当に検索。

http://ja.dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fja.dbpedia.org&query=select+distinct+%3Fs+where+%7B%0D%0A++%7B+%3Fs+rdf%3Atype+dbpedia-owl%3ACartoon+%7D+UNION%0D%0A++%7B+%3Fs+prop-ja%3AwikiPageUsesTemplate++template-ja%3A%E6%BC%AB%E7%94%BB%7D+.%0D%0A++%7B+%3Fs+foaf%3Aname+%3Fname+%7D+UNION%0D%0A++%7B+%3Fs+rdfs%3Alabel+%3Fname+%7D%0D%0A++FILTER+regex%28%3Fname%2C+%22%28%E3%80%82%7C%E3%80%81%7C%3A%7C%5C%5C.%29%24%22%29%0D%0A%7D+LIMIT+1000&should-sponge=&format=text%2Fhtml&timeout=0&debug=on

クエリは

select distinct ?s where {
  { ?s rdf:type dbpedia-owl:Cartoon } UNION
  { ?s prop-ja:wikiPageUsesTemplate  template-ja:漫画} .
  { ?s foaf:name ?name } UNION
  { ?s rdfs:label ?name }
  FILTER regex(?name, "(。|、|:|\\.)$")
} LIMIT 1000

Permalink | 記事への反応(0) | 18:43

2018-09-22

■JWTに関してのお伺い

http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session

適当にコメントを書いたら

スーパーエンジニアに「そういうことではない」

と厳しい叱責を受けたため、無能の見識を書いてみた。

「聞くは一時の恥、聞かぬは一生の恥」のとおり、

せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存

expの期限と任意でセッションが切れないデメリットに対する私見

作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)

私は無能なのでたぶんユーザーから報告を受けて

確認している間に1時間はかかるからいいやと思ってしまっていた

師はきっとJWT生成直後3秒でユーザーが

「これは、セッションハイジャックか・・・！？」

と気づいて通報

そして師が2秒で

「これは、セッションハイジャックだ！」

と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している

これは確かにJWTだと厳しそうだ

そもそもログインできるアプリなら

セッションハイジャック成功直後にパスワードを変更された場合

セッションを任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか

(師はログインを即座に検知してセッションを切れるから問題ないのか)

とにかくアカウントロック機能を作れば上記の懸念全てにきれいに対応できそうに見えている

「定期的な鍵交換が必要」に関する私見

この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える

これはまずい、自分の今までの見識の甘さを思い知らされた

今使っているフレームワークのリファレンスを見たが

keyは初回に設定したのみで、定期的な交換を勧める文が見つからない

私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか

JWTはhash化してつないでいる前提で

hashのkeyを総当たりで破る仮定で書く

私は無能なのでライブラリを用いることにしている

32文字のkeyが生成された

解読時間は下記を参考に、計算はwindows10の電卓アプリを用いて手動で行った

https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83

英数字大文字小文字で約60の時は10桁で20万年と書いているが

現代の解析技術は20万倍は速度が出ると仮定して1年として計算する

果たして、どのくらいの速度で鍵はやぶられると推定されるのか

とりあえず60を10乗した時点で(20文字相当)

6.0466176e+17

日本語に直すと60京4661兆7600億年かかる計算となった

実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ

これだけ長くともkeyの交換は必要なのであろうか

そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか

「JWTはセッションIDを含めれば安全」に関する私見

師から「そういうことではない」と指摘された点である

私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる

まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと

JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークンは実装しなかったことを告白しておく

そのためapiサーバで上記前提で用いた場合に考えたことを書く

webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく

JWT送信→user_id取得

では危険で

JWT送信→セッション(cookie形式?)送信切り替え→セッションからuser_id取得

だと安全になるのか検討する前提で記載する

とりあえず思いついたのは下記だった

通信途中で傍受されてログイン情報が奪われる危険が上がる
アプリから直接ログイン情報が奪われる危険が上がる

通信途中で傍受される危険に関して

tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能な識別子)が含まれる

おそらく一般構成の仮定で書く

httpsで通信するのでパケットキャプチャによる傍受は不可能と思っていた

(httpで通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)

0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない

というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので

JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった

※余談だが、たまに送る回数が少ない方が安全という

言説を見るのだが、個人的には上記の理由で納得できていない

アプリから情報が抜かれる危険性に関して

クライアントがネイティブアプリの場合、

攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた

(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)

その前提のため、わざわざ

JWT送信→セッション(cookie形式?)送信→セッションからuser_id取得　

で接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる

つまりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった

結論

つまりcookieだろうがjwtだろうがidとpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメントの発言に至った

ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが

それならもっと無駄なため考慮しない

セッションにするメリットとして唯一思いついているのは任意にサーバ側でセッションを切れることだが

それを指していたのであろうか

それは最初の段落の問題と同一と思っている

余談だが、ブコメの雰囲気に日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)

というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが

結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので

正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている

強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか

でも暗号化したらよいのでは、と思った

私的結論

expの期限と任意でセッションが切れないデメリットに関して

expを適切に設定しつつ、必要ならアカウントロック機能を入れる

(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)

定期的な鍵の交換について

長いkeyを設定すれば不要

「JWTはセッションIDを含めれば安全」について

少なくともapiサーバ→ネイティブアプリに関して、セッションIDを含めても危険性は変わらない

正直webアプリでも大して変わらんのでは、と思っているのは内緒である

と思ったので短慮なところ、見落としている視点があるようなら今後のためにご教示をいただきたく

以上、よろしくお願いいたします

Permalink | 記事への反応(0) | 11:52

2018-09-06

■プロデューサーよ、お前らの愛は結局金か？

どうも、元アイマスPです。

元、というのは私はもうすでにPを引退したからです。

現状アプリの類は消去しました。

グッズの類が大量に残っていますが、まぁいずれ処分するでしょう。

今回このブログを書こうと思ったのは、私のとある胸糞悪い経験を吐き出しておきたかったのと、これを見たPさん、あるいはアイドルマスターに限らず、いわゆる課金系アプリゲームをプレイしてる全ての人に表題の内容を問いかけたいからです。

課金ゲームにおける「愛」は結局課金でしか測れないのか？という事

アイマス風の言い方をすれば

プロデューサーの「担当愛」は結局課金額でしか測れないのか？

という事です。

事の発端は2年前、私がサークルの先輩からアイドルマスターを勧められた事に始まります。

私はどちらかというとオタク系コンテンツはそれなりに嗜んでいたのでアイマスもすぐにはまり、のめり込んでいきました。

アニマスから入り、劇場版で気になった後輩の子達を見てミリオンライブを始め、シンデレラガールズ、SideMと次々にどハマりしていきました。

改めて説明するまでもないと思いますが、アイマスにはゲームとライブがあります。ゲーム内のガシャを回し、イベントを走って担当のSRカードをゲットする。ライブで声優さんのパフォーマンスを見て感動して「アイマス最高」と唱える(笑)まぁそんな感じで各々楽しんでると思います。

コンテンツを応援するにはいろんな方法があります。ゲームに課金する、ライブに参加する、グッズを買う、二次創作をしてみる。

楽しみ方は本来人それぞれであり、それぞれがそれぞれの形で趣味を謳歌しています。

私の楽しみ方は基本的にライブに参加する事でした。

アイマスにハマった当初、私はまだ学生でした。

学生のアルバイトでは月々稼げる金額はどんなに頑張ってもたかが知れています。

どんなに頑張っても、社会人が月々稼げる金額になど到底及ばない事は想像に難くないでしょう。

アイマスを含めいわゆるソーシャルゲームには「天井」が設けられていることが多いです。

ガシャなどで「この金額までつぎ込めば必ず目当てのカードが手に入りますよ。」というボーダーラインだ。

ゲームにもよるがアイマスは大体ソシャゲの方は5万くらい、音ゲーアプリの方だと10万程度だろうか。

5万10万など学生にとってはかなりの大金である。

それ以上を稼ぎ出せたりお小遣いをもらっていたりと状況は様々だがこの金額を毎月叩き出せる人は全国でもそんなにいないだろう。

さらにイベントでランキング上位に到達するためにも上記レベルの課金はある程度必須と言っていい。

私は各コンテンツ(当時3つ)毎に「担当(他のコンテンツで言うところの「推し」)が複数人いた。

一人がイベントないしガシャで来たら5〜10万ぶっ飛ぶのである。

しかもそれが複数人いると言うことは数ヶ月に一回レベルでその出費、ましてやイベントが重なろうものなら倍プッシュである。

どんなにバイトを増やして掛け持ちしても追いつけるものではない。

そもそもバイトを増やしたら肝心の学業遊び就活諸々に支障が出る。

でも、担当の事は本当に好きだから何かしらの形で応援したい。

なので私はライブを中心に応援することを選んだ。

ライブなら事前に日程が設定されているのでそれに向けて貯金ができる。

ライブを通じて金銭面でも、気持ち的にも担当やコンテンツを応援できる。

そう思っていた。

だが、アイマスを布教してくれた先輩(仮にN氏としよう)は違った。

彼は社会人である。しかもどうやらそこそこ良い仕事をしていると見られる。

毎月のように一定数の金額を彼の担当のガシャやイベントに費やし、コンスタントに入賞していたところを見ると間違いない。

彼はいわゆる「ライブ勢」が大嫌いで、「声優のライブを見て何が面白いんだ」

「こいつらがライブにつぎ込んだ金を直接課金すれば良い話だ」

「こいつらは声優オタとしては一流だがアイマスPとしては三流」

などと事あるごとにこき下ろしていた。

まぁ、いわゆる「在宅」というやつである。

彼はサークルのOBでオタク仲間の中の中心的な存在だったため、同期後輩もなかなか彼に意見する事は難しかった。

それを知ってか知らずか、彼はその集まりの中で二言目には「プロデューサーの流儀」を語りたがり、「コンテンツに課金できない奴は三流のにわか」という定説を偉そうに唱えていた。

私はミリオンライブが初めて触れたアイマスだったため、イベントの走り方など分からず、中途半端な課金額で爆死するということを繰り返していた。

といっても前述した通り、学生にとっての大金を定期的にぶち込めるなんて暴挙ができるわけがないので突然イベントが告知されて担当が上位報酬に来てさぁ走れと言われたって走れるわけがない。

突然の出費もある、月々のいろんな支払いがある。それを社会人と比べれば微々たるお金の中で工面してるのだ。趣味であるゲームに対する優先順位なんて、お察しである。

それでもなんとか工面したお金をつぎ込んだところで結果は散々たるものだった。それを知ったN先輩は事あるごとに

「お前の担当愛はその程度なのか？」

「中途半端な事しかできなくて担当に申し訳ないと思わないのか？」

「おい爆死野郎w」

とバカにしてきた。

自分は担当が本当に好きだったからそれなりに調べてるし、イベントも出来る限り追ってるし、二次創作を出してみたりもした。何よりライブは担当が出演すると分かれば必ずCDを積んだり、e+に殴りこんだり、最悪友達を頼ってでも必ず参加した。極力現地で。

それなのに爆死したら担当を名乗る資格がないのだろうか？

ゲームに課金できなかったら担当としてダメなのか？

そんな漠然とした疑問が胸の内を占めていた。

だが、所詮趣味だし、好きでやっている事だからと気に留めていなかった。

今年の3月、あの日が来るまでは。

大学を卒業した私はサークルの追い出しコンパ(追いコン)に参加した。

1年生から4年生まで数十人という大規模な追いコンで、サークルで顔を合わせるけど名前は知らない後輩も数多くいた。

N先輩も参加していた。

追いコン事態は順調に進み、最後に4年生が一人ずつ挨拶をするときに事件は起きた。

自分の番になった時にN先輩が

「よっ！三流クソにわかP！」

「爆死野郎！」

と大声で叫んでいたのだ。

みんなに聞こえる声で

流石に私も堪忍袋の緒が切れた。

いくらなんでも後輩が何十人もいる前でそんなこと言わなくても良いじゃないか

これでは卒業間際の最後の最後で飛んだ赤っ恥である。

その時は笑って流したが、後日、新歓のミーティングに顔を出していたN先輩に詰め寄り、あの時の発言の意味を説明し、訂正して欲しい。本気で恥ずかしかったんだからみんなの前で謝罪してほしいと訴えた。

すると、彼の隣にいた別の先輩(A先輩とする)が顔を真っ赤にして怒り、怒鳴り散らし始めたのだ。

彼の主張を要約すると以下の通りである。

・先輩に向かってその態度はなんだ。

・大勢の前で生意気な態度を取ったお前もNの事を貶めている。お前にNを断罪する資格などない。お互い様だ。

・そもそもアイマスにおいて何を持って担当とするかなんて人それぞれで明確な基準などない。お前の主義主張を押し付けるな。

私はとても惨めな気持ちになった。

私はただ、あの時の発言を取り消して欲しかっただけで、せめてみんなの前で謝って欲しかっただけなのに…

これではただの公開処刑ではないか。

するとA先輩の怒りっぷりを見たN先輩はへらへらと笑いながらA先輩をなだめ、以下のような主張を始めた。

・酒の勢いで言っただけだ、気にするな。

・お前が○○(私の担当)をいかに愛してるのかはみんながよく知っている。

・なのにも関わらずイベントの走り方が下手くそだから私はそれをいじってるだけ

・自分は昔ライブ専門でゲームに全く金を落とさない同期に「お前はだから三流なんだ」と言われたことが本当に悔しかった。お前にそうなって欲しくないからああやって言ってあげてたんだ。

彼の口から、最後まで「後輩数十人の前で私の名誉を貶めた事に関する謝罪の言葉」はありませんでした。

これを期に私はアイマスから遠のきました。百年の恋も冷める瞬間とはこの事なのでしょう。

アイマスPは課金額で他人にマウントを取り合うような人間しかいないんだなぁ

こんなデータがクラッシュしたら吹っ飛ぶ画像にうん万円も賭けなきゃ担当名乗る資格がないのが、Pの常識なんだなと察してしまいました。

ここまでの話を聞いて

「別にこの先輩がおかしいだけ。」

「増田が考えすぎ気にしすぎ。」と思う人が大半なのではないかと思います。

ですが、私がこの件について許せないのはそこだけではないのです。

私の担当は 田中琴葉でした。

そう、中の人である種田梨沙さんが昨年活動を休止されて、ミリシタでの実装が大幅に遅れた、あの田中琴葉です。

私は、声優さんの不在によって琴葉の存在がだんだん希薄になっていく事をずっと悩んでいました。

4th Liveでも現地で感じた「琴葉が置いていかれてるのではないかという不安」にずっと悩まされていました。(最後のThank youでそれが解消され、安心から大泣きしてしまいましたが笑)

ちょうど就職活動中だった事もあり、イベントになかなか課金ができず、どうすれば琴葉を応援できるのか、どうしたらミリシタから入ったPさんに琴葉がここにいると示すことができるのか、ずっと悩んで、苦しんで、精神をかなり病みましたがそれでも2月に琴葉がミリシタに実装されてやっとこれからなんだと思いました。

自分も就職が決まり、やっとこれから琴葉にたんまりお金を使ってあげられる、本気でプロデュースできると思っていました。

その思いを、悩み抜いた思いの全てを、N先輩はみんなの前で汚い足で踏みにじったのです。「課金額が少ない」「ゲームに投資してない」たったそれだけの理由で。

もう一度言いますが、わたしはライブを中心にお金を落としています。

ライブだけに費やした金額なら数十万に上るでしょう。

でも、それ以外に一切お金をかけていないということではありません。そんなこと有り得ません。

グッズも買ってるしCDだって全て新品で揃えたし肝心のゲームにだって課金してます。

学生時代はイベント時に1,2万が限度でしたがそれでも担当が来たら必ず走って回すようにしてます。

それでも足りないのでしょうか。

担当が取れなかったらその時点でP失格なのでしょうか。

私はあの日大勢の前で3流にわかと罵られないといけなかったのでしょうか。

もう全てがバカバカしくなってしまいました。

5thは一応参加しました、最高でした。

でももう自分のアイマス人生はこれで終わりだなと思いました。

あんな辱めに公開処刑まで受けては大学の後輩や同期に顔向けできないからです。

いまだにガシャやイベントが来るたびにN先輩の言葉が、あの日の恥ずかしさ惨めさが胸をよぎって、まっすぐアイマスを愛することができないからです。

もうすでに周囲には引退を伝えました。

N先輩はいずれ勝ち誇った顔で「やっぱりあいつはその程度だったかw」と話すことでしょう。

画像データ音声データにうん万もぶち込んで一生イキってろバカ。

Permalink | 記事への反応(11) | 19:16

2018-08-30

■anond:20180830191405

Santa Cruzが来てもどうせワイヤレスは技適通らないので、今VIVE+TPLINK+フルトラセット買うのが正解やぞ。

Permalink | 記事への反応(2) | 19:22

2018-07-04

■anond:20180704102549

https://anond.hatelabo.jp/20180618192659

3個芝の例を見つけたぞ低能ｗｗｗ

たぶん同じことを何度も言わせるとそのたびに増えていく感じだぞ低能ｗｗｗ

「NEW GAME+++」みたいな感じだなｗｗｗ

Permalink | 記事への反応(1) | 10:31

2018-05-23

■anond:20180523132351

最近はnode+seleniumやゆうとるやろが。(割と遅くて困ってるが)

Permalink | 記事への反応(0) | 13:25

2018-04-12

■ライムスターってRHYME+Starだと思ってたんだけど、Rhymest+erなんだな。

rhymestって都都逸野郎とかそんな感じの蔑称な気がするんだが…

Permalink | 記事への反応(1) | 09:12

2018-02-12

■IPoEでも遅い

八方手を尽くして調べたんだが結局わからなかった

2ヶ月だけ100Mbps出ていたんだが、今や300kbps〜6Mbps

　

一体何が起きているのか分からない

IPoE+DSLiteは確かに動いている

でもIPv6の速度チェックでも遅い

　

もうわからん

疲れた

夏か秋までに引っ越して、au光かNuroを導入するしかない（今のマンションは全部NGだった）

Permalink | 記事への反応(1) | 19:13

2018-01-14

■anond:20180113230800

古代ローマ　黒人　で検索

ローマ時代のブリタニアに暮らした黒人女性「象牙の腕輪の貴婦人」

https://gigazine.net/news/20100302_ivory_bangle_lady/

『古代アフリカ・エジプト史への疑惑』第7章9

http://www.jca.apc.org/~altmedka/afric-70-709.html

古代ローマ人の24時間　よみがえる帝都ローマの民衆生活

https://books.google.co.jp/books?id=Srw_DwAAQBAJ&pg=PT196&lpg=PT196&dq=%E5%8F%A4%E4%BB%A3%E3%83%AD%E3%83%BC%E3%83%9E+%E9%BB%92%E4%BA%BA&source=bl&ots=DCY8F5D5K1&sig=oESQPrtl4UbxrSwAcwYUhinvTZ0&hl=ja&sa=X&ved=0ahUKEwiy9PG2uNfYAhUGE5QKHXYIBrw4ChDoAQgoMAE#v=onepage&q=%E5%8F%A4%E4%BB%A3%E3%83%AD%E3%83%BC%E3%83%9E%20%E9%BB%92%E4%BA%BA&f=false

古代ローマ帝国は、黒人の住む地域まで拡大している。

属領からは奴隷が本国に供給されていた。

奴隷は一定の条件を満たすと解放奴隷となりローマ市民権を得られた。

故に、古代ローマ帝国を描いた作品に黒人が登場するのは当然である。

平たい顔族がローマにいたのかは定かでは無い。

Permalink | 記事への反応(0) | 21:26

2017-11-23

■ポケ森よりぶつ森e+の方が面白い

懐古補正無しに過去作の方が面白かったのは間違いない。ハードの違いによるゲーム性云々抜きに。下手すりゃ64版の方が良かった。

というわけで恐らく出るであろうスイッチ版に期待

Permalink | 記事への反応(1) | 22:21

2017-10-10

■増田のrails屋、ちょっと教えろ

ミーにはステマ起点に見える

IntelliJベースのRubyMine（完全有料：個人紐付ライセンス1万円/年（税込））がベター

IntelliJは使ったことあるかな

あれの有償版Ultimate+Ruby特化+Railsプラグインみたいな感じ

1か月の試用期間付き

Permalink | 記事への反応(1) | 12:51

2017-10-06

■最近のアイドルマスターsideMについて思うこと

アイドルマスターsideM！！！

10/7、アニメ第１話放送！！！

に喜んでいる、315プロのアイドルに声がつく前からポチポチ頑張っていたPです。

ここまで、とても短かったなぁ、とも思うし、とても長かったなぁとも思います。

担当のイベントRカードが初めて出た日、

担当の初めてのイベントSRカードがガチャで課金の仕方がわからず涙を飲んだ日、

担当のグッズを初めて手にした時、担当の声が決まった日、

担当の声がゲームで実装された日、

担当のCDを買った時、

ライブで担当がパフォーマンスをした時、

新アプリリリースが決定した時、

アニメ化が決定した時、

新アプリがリリースされた時…

最初は担当中心にゆったりまったり楽しんでいたのに、最近では公式からいろいろな情報や媒体が出て着て、てんやわんやで目を回しています。

特に2ndが終わり、アニメ化が発表されてから今まで、ものすごい勢いで時が流れていった気がします。もう3rdやるの？嘘でしょ？

THE IDOLM@STER Prologue SideM -Episode of Jupiter-も放送されましたね！！

私は副業でリアタイできず、録画して後から見ました。

EOJの円盤が出ると先に聞いて、うーん、でもJupiterPじゃないし、sideMからJupiterを知った新参だし、買わないでおこうかなぁ…って思ってたんですけど、見終わった後、涙を流しながら円盤買う…カレーも買う…って決意しました。ありがとうアイマス、ありがとうJupiter。

そして！！！！第1話が10/7に放送される！！！！やった！！！すごい！！！正直もう5年はかかると思っていた！！！ありがとう！！！ってテンションは最高潮なんですけど、それと同時にある不安も結構なところまできてるので、ちょっと吐き出させてください。

アイドルマスターsideMには、個性的で魅力的なユニットが合計15ユニットあります。

アイドルマスターsideMの初めてのライブ、通称ファスライには、6ユニット出演しました。アニメ化のキービジュアルにもなってる6ユニットです。ここでは、この6ユニットをファスライ組とここでは呼ばせてもらいます。

アイドルマスターsideM2回目のライブ、通称セカライには、全てのユニット、15ユニット出演しました(Jupiterは御手洗翔太役の松岡禎丞さんのみでしたが…)。2ndで初めて出演した9ユニットをセカライ組と呼ばせていただきます。

この呼び方、賛否両論あると思うんですけど、わかりやすいのでこう呼ばせてもらいますね。

ここまで書いたら察しのいい方はなんとなくわかったかもしれませんが、不安というのは、最近のセカライ組の露出の少なさです。

アニメ化の最初は少なくとも1クールはファスライ6ユニットを中心に話が進むと思います。いわば、今回のアニメ化の看板、キービジュアルやグッズやキャンペーンが多いのも納得です。納得してきました。

その納得が不安に変わったのは、ナンジャタウンのキービジュアルを見てからです。

猫耳燕尾服！！！ちょーかわいい！！！そしてかっこいい！！！そう思いました。と、同時にこうも思いました。

担当の猫耳燕尾服は？

私の担当は、複数います。ユニットで応援している子もいれば、単体で推している子もいます。その子たちはみんなセカライ組です。

セカライ組のやっかみか！！！！って言われるとそういうわけじゃないんですけど、やっぱり、考えてしまいます。

アニバの衣装もまだ一部着てないし、アニバのCDも出てないし、アニメのキービジュアルも出てないし、アニオンとかの新規グッズも出てない…

アニメPV出たやんけ！！！って言われますけど、あれはあくまで「前職」の彼らであって、「アイドル」の彼らではありません。「前職」の彼らも見たいですけど、それ以上に「アイドル」の彼らが見たいです。

ここまでセカライ組の露出？キービジュアル？が少ないと、アニメ情報だけ見てる方はセカライ組いないって思わない…？ゲームやろう？？

セカライ組だけでライブしろや！！！セカライ組だけでアニバCD出せや！！！！ってことは思ってないです。でも、今ファスライ組はアニバ曲を歌っていて、セカライ組は歌っていないっていうのは事実なんですよね。

担当のユニットにぴったりな声と歌を贈ってくれた販売元を信用しているし信頼しているから、アニメもキービジュも絶対出るし、アニバの曲は全ユニットで出るし、担当も猫耳で燕尾服って信じてます。

信じてるけど、やっぱり不安なんじゃ〜！！！！うお〜！！！！

アニバは正直めちゃめちゃ不安です。この調子でいったら担当がアニバ衣装着るのヘタしたら1年以上たちます。なんで〜？？？？早く着て！！！！

Mステの方も、一部恒常SR未実装だし、イベントで実装された！！！って思ったらイベントがリズムゲームほぼ関係ないし、なんなんだー？！？！って感じです。なんなんだー？！？！？！正直アニメ絵柄SRより先にいない子の恒常SRが欲しかったな…な…

担当が全員ファスライ組の友人にいやでも出るやろ！！って言われても、お前にこの気持ちはわからんだやろ！！！！！って思ってしまいます。

出ないことが不安っていうより、出るかどうかわからないものに期待を寄せ続けるのがしんどいんだと思います。

何回も言ってるけど、ファスライ組にもう出るな！！！って言いたいわけじゃなくて、セカライ組も出したげて！！！ってだけなんですよ。

ただただ

担当の新しいキービジュアルが見たい！！！

担当の新しい歌が聞きたい！！！

ってだけなんです。

まあ！！！！アニメ2クールでは担当が死ぬほど出て、CDも買いきれないくらい出て、アニメが終わる頃には劇場版も発表されて、シャッフル企画の仲間にもいれてもらえて、アイマスありがとう…って涙を流してると思うので！！！！

思えば担当の声がつくまでもやっぱつかないんじゃない…？？ってめちゃめちゃ不安だったので、そんなもんなのかな！！！

グチャグチャな文をここまで読んでくれてありがとうございます！！とにかくアニメすっっっっごく楽しみです！！！早く動く彼らが見たい！！！！3rdライブも楽しみ！！！現地参戦イメトレは完璧なので、あとは結果がついて来るだけです！！頼むぜe+！！！！！





















でももし万が一セカライ組が出なかったら泣きながらカレー食べます。

Permalink | 記事への反応(1) | 01:50

2017-09-06

■ローチケの信用のなさ

Amazonとかならな、キャンセル連絡なんかきたらまず自分の操作ミス・対応ミスを疑うんだけどな。知人がそうだって話してたとしても、そういう理由があったんじゃないかって思うし。

ローチケ(だけじゃなくてぴあやe+も)はさぁ、向こう都合で勝手にチケットキャンセルしておいて厚顔無恥にも『自分達が絶対正しいです』って言いそうな印象あるから、自分のミスより悪意疑うよね。ローチケの信用ってそんな感じ。JASRAC並み。

今回騒ぎを起こした人をどのくらいフルボッコするつもりなのか分かんないけど、そんな他の客がドン引きするようなことに力を入れるより『チケットは興行主よりお預かりしているだけであり、弊社の自由にできるものではありません。安心してご利用ください』みたいな説明を懇々としていくべきではないだろうか。

Permalink | 記事への反応(1) | 02:13

2017-09-03

■Raspberry PiとLIRCによるエアコン操作でハマったこと

先人のあとを辿る。

エアコン信号は長いので、irrecordではできない。

mode2で信号を記録して、整形後にconfファイルに貼り付ける。

スクリプトを作って変換してもいいけど、

　-mオプションをつければ、最初から貼り付け可能なフォーマットで保存できる（ただ、後述の分析時はつけないほうがよい）

ここまでは良かった。

ところが、エアコン以外は操作できるのに、肝心のエアコン（ダイキン製）は操作できない。

原因は記録時にpulseとspaceの割合がずれること。

エアコンはデータ量が多いためか、周期(ticks?)が短く、

ズレの影響が許容値を超えるんだと思われる。

本当は1:1になるべきところが、5:3とかになる。

なので、pulseとその次のspaceを足して２で割った値を並べ、あるべき時間を推測する。

つまり、データビットは1:1か1:3なので、そうなるように補正してやる。

大体一定の時間だけずれているので、適当な代表値を決めて、

全データに対して、シフトさせるだけでも動く場合が多い。

(pulse'=pulse-⊿、space'=space+⊿）

ただ、ときどき変な長さが交じるので、

ちゃんと長さを読み取って、あるべき時間を吐かせるとなお良い。


その他

  • Raspbian (Stretch) でのLIRC設定は→に書いてある。助かる。http://raspibb2.blogspot.jp/2017/
  • mode2で記録するときに、頭に長いspaceがついてないやつは記録失敗している。
  • confファイルでraw codeがちゃんと奇数個になってないと動かない。一箇所でも間違っていると、unknown remote: "xxxx"って言われるので、わかりにくい。


おわり。

Permalink | 記事への反応(0) | 08:36

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