KTSee.eu.org

API接口 你可以通过调用Matomo的分析接口将数据集成到其他应用中去。这些数据包括访问数，页面网址、网页标题、用户设置、搜索引擎、关键词、推荐网站、用户浏览器 其中的请求参数和返回值需要对照官方手册来 未定义 ## API `未定义` ## Annotations `未定义` ## Contents `未定义` ## CoreAdminHome `未定义` ## CustomDimensions `未定义` ## CustomJsTracker `未定义` ## CustomVariables `未定义` ## DBStats `未定义` ## Dashboard `未定义` ## Events `未定义` ## Feedback `未定义` ## Goals `未定义` ## ImageGraph `未定义` ## LanguagesManager `未定义` ## Login `未定义` ## Marketplace `未定义` ## MobileMessaging `未定义` ## PagePerformance `未定义` ## Provider `未定义` ## SEO `未定义` ## SitesManager `未定义` ## TagManager `未定义` 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Actions 动作（行为） Actions.get 访客分析-概述-访客概览(右边一列) Actions.getPageUrls 行为-页面 Actions.getPageUrlsFollowingSiteSearch Actions.getPageTitlesFollowingSiteSearch Actions.getEntryPageUrls 行为-进入页面 Actions.getExitPageUrls 行为-退出页面 Actions.getPageUrl 行为-通过页面的PageUrl查看详情(获取单条记录) Actions.getPageTitles 行为-页面标题 Actions.getEntryPageTitles 行为-页面标题-进入页面标题 Actions.getExitPageTitles 行为-页...

微信小程序使用起来感觉像写h5一样，对于新手估计会有比较多疑惑，如果撇去这些想法应该是很快就能上手的一套开发方案。 但是它自身的限制也比较大，如不提供window对象会导致一些功能实现起来比较麻烦。我这次开发的小程序就遇到了，虽然比较快找到解决办法（可能都是比较标准化的东西），希望之后不会有其他大坑。 需要其实比较简单，就是两页文章列表及文章详情页，刚上手却遇到下面的坑： 无法利用window对象解析xml 不支持HTML标签的使用 怎样兼容Promise和generator异步 刚开始一脸懵逼...后来赶紧去github看看各大牛例子及一些工具就解决了。 解析xml问题 由于比较多的解析插件都是基于 window.DOMParser 处理的，在小程序却无用武之地。找到问题就好解决，我要的是 DOMParser 而不是window找找应该有代替品，然后找到这个 xmldom 引入代替掉 DOMParser 就解决，然后把xml转成json处理了。 评论有问道如何改，这里我已经把这个整合到 这库 了。 解析html问题 现在比较成熟的是 wxParse 这货，的确大部分的html标签均能解析渲染，但是我这边程序录入的富文本内容却掺杂了些奇奇怪怪的标签，解析时还是会出错，内容解析到一半就停了...既然它做不到忽略，咋整？那把那些垃圾都过滤掉吧！！！马上用上 js-xss 这个来处理问题，能控制过滤的标签及标签能拥有的属性，方便得很。 const xss = require ( '../lib/js-xss/xss' ) const WxParse = require ( '../../lib/wxParse/wxParse.js' ) //把style及class添加到白名单。 Object .keys(xss.whiteList).forEach( name => xss.whiteList[name] = xss.whiteList[name].concat([ 'style' , 'class' ])) let content = xss( '<div>HTML文本</div>' , ...

有时候我们希望能分析一下web服务器的访问记录，如果是直接打开 /var/log/nginx/access.log 的话，虽然的确可以看到访问记录，但是数据太多了，也很难直观的分析出我们想要的结果。而使用命令来分析虽然可行，但是命令比较难记忆，也不算直观。 今天了解到了一款轻量易部署的工具—— goaccess ，可以用来将我们nginx服务器的访问日志可视化，将数据直观的展现给我们。 除了nginx日志，该工具还可以将apache等服务端的日志可视化展示 安装GoAccess 官方给出了 安装教程 ，有linux包管理器安装，源码编译安装，docker镜像等多种部署方式，由于ubuntu18源里面的goaccess版本还算比较新，可以直接使用 sudo apt install goaccess 来安装 强烈建议不想折腾的话直接用包管理器安装！！！体验基本是相同的 。 不过这篇文章中我计划直接下载源码编译安装最新版，获得最新的体验: 我计划使用geoip city的mmdb数据库(一开始我以为可以精确到城市，但是查看github issues发现他们其实还没做精确到城市的显示…),所以得先去下载geoip2的数据库  https://www.maxmind.com/  需要注册才能下载，还不能挂代理。 bash # 首先安装依赖避免出现下面那些报错 sudo apt-get install libncursesw5-dev libglib2.0-dev libgeoip-dev libtokyocabinet-dev libbz2-dev $ wget https://tar.goaccess.io/goaccess-1.3.tar.gz $ tar -xzvf goaccess-1.3.tar.gz $ cd goaccess-1.3/ $ ./configure --enable-utf8 --enable-geoip = mmdb --enable-tcb = btree #这里的各个配置可以查看教程中的介绍如果要开启ssl 使用 --with-ssl参数 $ make $ make install 第一次尝试安装出现报错 checking for MMDB_open in -l...

一次偶然原因，在网上看到关于一些Mifare Classic card卡的破解文章,发现成本不是很高,并且门槛也不太高（本人笨得很,没觉得低）觉得很有意思，准备入坑一波。正好我寝室有饭卡、洗澡卡和直饮卡,爲啥不试一试呢,嘿嘿.说干就干! 于是乎就在网上各种收集资料,(本人懒得很,不想去图书馆查资料)首先我们得搞懂M1卡的内部结构是吧，不然无从下手啊,所以我们先从结构说起吧. 可能文章有点长，着急的话可以直接跳过前面三个点 1.M1卡的存储内部结构： M1卡分爲16个扇区，每个扇区对应4块（块0-块3）,共64块，编号爲0-63.第0扇区的第0块用于存放厂商代码，已经固化无法更改。其馀区的第0-2块用于存放数据，块3爲控制块用于存放密码A、存取控制、密码B，结构如下：      A0 A1 A2 A3 A4 A5     FF 07 80 69    B0 B1 B2 B3 B4 B5      (密码A 6字节)     (存储控制 4字节)    (密码B 6字节) 并且每个扇区块3中的密码和存储控制全部都是独立的，独立控制本扇区的各种操作，每个扇区都能实现不同的功能，所以广泛用作一卡通。存储控制里面4字节的具体含义我也不是很清楚(不影响我们破解)，所以就不说出来误导大家了。 卡中每个块包含16字节，所以M1卡的容量=16扇区*4块*16字节=1024字节=1k  (M1卡的由来)。 知道了M1卡的大致结构我们就可以开始进行破解了，我在此收集了几种常见的破解手段。 2.M1卡的破解原理：   1）暴力破解： 暴力破解是最简单粗暴、不需要多少技术含量的，就是比较费时，但这并不妨碍大家对它喜爱之情。因爲M1是被动卡，需要读卡器爲之供能，一旦读卡器切断电源，卡中临时数据就会丢失，所以无论试错多少次密码都不会被锁定。特别是一些厂商偷懒用弱密码，花不了多少时间就能破解。 2）克隆卡片： 这算是最简单又实用的方法了。因爲M1卡加密扇区里面保存着各种数据，所以可以克隆一张带有同样数据的克隆卡。这就会用到一种叫UID卡的特殊M1模拟卡。前面说过，每张卡在0...

本文是Ebay的架构师在2008年发表给ACM的文章,是一篇解释BASE原则,或者说最终一致性的经典文章. 文中Dan讨论了BASE与ACID原则的基本差异, 以及如何设计大型网站以满足不断增长的可伸缩性需求,期间如何对业务做调整与折衷. 以及一些具体的折衷技术的介绍. 在数据库分区中，以一致性换取可用性会显著提高系统伸缩性。 在过去的十年里，网络应用越来越普及。不管你正在为终端用户还是应用程序开发人员构建应用程序(即服务)，您都希望您的应用程序得到广泛的采用，而广泛采用将会带来交易增长。如果您的应用程序依赖于持久化，那么数据存储可能会成为您的瓶颈。 有两种方法可用于扩展任何应用程序。第一个，也是最简单的，是垂直扩展:将应用程序移动到更大的计算机上。垂直扩展不影响数据的合理性，但是有几个限制。最明显的限制是超过系统的最大可用容量。垂直扩展也很昂贵，因为增加交易容量通常需要购买下一个更大的系统。垂直扩展通常会带来供应商依赖，从而进一步增加成本 水平扩展提供了更多的灵活性，但也相当复杂。水平数据扩展可以沿着两个维度进行。功能扩展，包括按功能分组数据，还有将不同的功能组分布到不同数据库。第二个维度是在功能区域内分割数据，分布到不同数据库，这也叫分片。图1说明了横向数据扩展策略。 如图1所示，水平扩展的两种方法都可以同时应用。用户、产品和事务可以在不同的数据库中。此外，每个功能区域都可以根据交易量跨多个数据库分割。如图所示，功能区域可以相互独立扩展。 功能分区 功能分区对于获得高的可伸缩性非常重要。任何优秀的数据库架构都会将schema分解为按功能分组的表。用户、产品、交易和通信都是功能的例子。利用诸如外键之类的数据库概念是保持这些功能区域一致性的常见方法。 依赖于数据库约束来确保跨功能组的一致性，会导致数据库在部署策略上的高耦合。为了使约束生效，表必须驻留在单个数据库服务器上，从而不能在交易数量增长时水平伸缩。在许多情况下，最简单的扩展方案是将功能组数据移动到相互独立数据库服务器上。 当交易量非常高的时候，不同的功能数据将在不同的数据库服务器。这需要将数据约束从数据库移出并在应用程序解决。这就带来了本文后面将讨论的几个挑战。 CAP原理 加州大学伯克利分校(University of California, Berkeley)教授、Ink...

1. 删除数组尾部元素 一个简单方法就是改变数组的length值: 1 2 3 4 5 6 7 8 const arr = [ 11 , 22 , 33 , 44 , 55 , 66 ] ; // truncanting arr . length = 3 ; console . log ( arr ) ; //=> [11, 22, 33] // clearing arr . length = 0 ; console . log ( arr ) ; //=> [] console . log ( arr [ 2 ] ) ; //=> undefined 2. 使用对象解构（object destructuring）来模拟命名参数 如果需要将一系列可选项作为参数传入函数，你很可能会使用对象（Object）来定义配置（Config）。 1 2 3 4 5 6 7 doSomething ( { foo : 'Hello' , bar : 'Hey!' , baz : 42 } ) ; function doSomething ( config ) {    const foo = config . foo !== undefined ? config . foo : 'Hi' ;    const bar = config . bar !== undefined ? config . bar : 'Yo!' ;    const baz = config . baz !== undefined ? config . baz : 13 ;    // ... } 不过这是一个比较老的方法了，它模拟了 JavaScript 中的命名参数。 在 ES 2015 中，你可以直接使用对象解构： ...

  前言 设计是把双刃剑，没有最好的，也没有更好的，而是条条大路到杭州。同时不设计和过度设计都是有问题的，恰到好处的设计才是我们追求的极致。 DDD（Domain-Driven Design，领域驱动设计）只是一个流派，谈不上压倒性优势，更不是完美无缺。 我更想跟大家分享的是我们是否关注设计本身，不管什么流派的设计，有设计就是好的。 从我看到的代码上来讲，阿里集团内部大部分代码都不属于 DDD 类型，有设计的也不多，更多的像“面条代码”，从端上一条线杀到数据库完成一个操作，仅有的一些设计集中在数据库上。我们依靠强大的测试保证了软件的外部质量（向苦逼的测试们致敬），而内部质量在紧张的项目周期中屡屡得不到重视，陷入日复一日的技术负债中。 一直想写点什么唤起大家的设计意识，但不知道写点什么合适。去年转到盒马，有了更多的机会写代码，可以从无到有去构建一个系统。盒马跟集团大多数业务不同，盒马的业务更面向 B 端，从供应到配送链条，整体性很强， 关系复杂，不整理清楚，谁也搞不明白发生什么了 。所以这里 设计很重要 ，不设计的代码今天不死也是拖到明天去死，不管我们在盒马待多久，不能给未来的兄弟挖坑啊。在我负责的模块里，我们 完整地应用了 DDD 的方式去完成整个系统 ，其中有我们自己的思考和改变，在这里我想给大家分享一下，他山之石可以攻玉，大家可以借鉴。 领域模型探讨 1. 领域模型设计：基于数据库 vs 基于对象 设计上我们通常从两种维度入手： Data Modeling : 通过数据抽象系统关系，也就是数据库设计 Object Modeling : 通过面向对象方式抽象系统关系，也就是面向对象设计大部分架构师都是从 Data Modeling 开始设计软件系统，少部分人通过 Object Modeling 方式开始设计软件系统。这两种建模方式并不互相冲突，都很重要，但从哪个方向开始设计，对系统最终形态有很大的区别。 Data Model 领域模型（在这里叫数据模型）对所有软件从业者来讲都不是一个陌生的名词，一个软件产品的内在质量好坏可能被领域模型清晰与否所决定，好的领域模型可以让产品结构清楚、修改更方便、演进成本更低。 在一个开发团队里，架构师很重要，他决定了软件结构，这个结构决定了软件未来的可读性、可扩展性和可演进性。通常来说架构师设计领域模型，开发人员基于这个领域...

从来不敢起油锅。 但自从加入没事干，看到艾格老师连葱油都炸得如此优雅，好想撸起袖子投身厨房这番大事业啊！ 可是， 看中餐菜谱像在猜灯谜！不是吗？比如 青椒炒肉丝，百度菜谱如下：         1.食材洗净；（多少食材？）         2.青椒 切丝 ，肉切丝，葱姜蒜切末；（怎么切丝？怎么切末？要花一个钟头切对吗？）         3. 炒锅入油加热，下入葱姜蒜 爆香 ，下入肉丝炒至变白，加酱油 少许 。（什什什么是少许啊？）         4.下入青椒丝 煸 炒4-5分钟，淋水淀粉 少许； （又少许，嘤嘤嘤……）         5.盛出装盘。 我用猜的，做出来的是这样（鬼一样）。 倒了「少许」酱油，明显咸了。肉丝炒老了，青椒没炒熟。 以上显然不是没事干研究院的水准。为了炒出一盘真正好吃下饭的青椒炒肉丝，我们 请教了上海市厨师资格证考官 ，埋头厨房苦心练习。 这才是一盘燃烧中华料理之魂的青椒肉丝！ 现在，我很淡定地在写这篇文章。 我保证，你看完之后，也能看得懂中餐菜谱。 “没事干研究院”的005篇文章。 我们是艾格吃饱了指导下的一个小小编辑部， 专门研究新手才会发愁的问题。 A 读懂菜谱第一章 买多少青椒，多少肉丝？ （1）记住这个 结论 ：按两人份算，像青椒肉丝这样的荤素小炒，一盘菜的分量大概在150～200g。 （2）新手不知道 食材比例 ，就按1：1来买，不会错。所以我需要100克青椒，100克肉。 但是，青椒要去芯，于是，我决定买2个青椒，二两肉。 这个青椒与iPhone6s同宽、8cm长，大约120g重，切丝后大概有50g左右。我称过，你就不用称了，有个参考就好。 B 读懂菜谱第二章 菜，到底要怎么切 青椒要与肉丝一起切成 统一规格 的丝儿，这是青椒肉丝好吃的关键！ 为什么青椒炒肉丝，最重要的是 切 法？ 问艾格，她说你明白刀工的本质吗？我们切食物， 不仅 是追求好看，也和味道有直接关系。整只青椒和整块肉下锅，炒不熟，不好吃。青椒切粗了，也炒不熟，会有生腥气。切得像头发丝一样细，不光浪费时间，也会吸太多油而失去脆感。 青椒和肉要切成多细，才会在时间和口...

最近因公司项目增多，且环境也越来复杂，开发人员找我查看错误日志越来越频繁，心里便念想到ELK，心之所想，念之所达，快来get一项新技能吧 1、系统架构组成 laravel日志：日志源通过filebeat将日志写进redis中间件 logstsh：logstash通过input将redis数据拿来分析，通过其filter模块分析所需要的语句，然后输出到elasticsearch 3.elasticsearch 接收logstash发送过来的数据，并提供了一个分布式多用户能力的全文搜索引擎 Kibana是一个优秀的前端日志展示框架，它可以非常详细的将日志转化为各种图表，为用户提供强大的数据可视化支持。 二、各个服务的ip地址 laravel: 172.18.109.227 redis: 172.18.215.207 elasticsearch: 172.18.215.207 kibana: 172.18.215.207 复制代码 三、laravel日志服务器配置： 配置filebeat yum源文件 [elastic-5.x] name=Elastic repository for 5.x packages baseurl=https://artifacts.elastic.co/packages/5.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type =rpm-md 复制代码 安装filebeat yum install filebeat 复制代码 配置filebeat配置文件 ... #写入源 - input_type: log paths: - /var/www/html/*/storage/logs/laravel-2018-12-29.log ... #输出至redis output.redis: # Array of hosts to connect to. hosts: [ "172.18.215.207:6379" ] password: "***********" db: 0 timeout: 5...

使用Java的小伙伴，对于Java的一些高级特性一定再熟悉不过了，例如集合、反射、泛型、注解等等，这些可以说我们在平时开发中是经常使用到的，尤其是集合，基本是只要写代码没有用不到的，今天我们先来谈谈 泛型 。 1. 定义 在了解一个事物之前，我们必定要先知道他的定义，所以我们就从定义开始，去一步一步揭开泛型的神秘面纱。 # 泛型（generics） 他是 JDK5 中引入的一个新特性，泛型提供了编译时类型安全监测机制，该机制允许我们在编译时检测到非法的类型数据结构。泛型的本质就是参数化类型，也就是所操作的数据类型被指定为一个参数 # 常见的泛型的类型表示 上面的 T 仅仅类似一个形参的作用，名字实际上是可以任意起的，但是我们写代码总该是要讲究可读性的。常见的参数通常有 : E - Element (在集合中使用，因为集合中存放的是元素) T - Type（表示Java 类，包括基本的类和我们自定义的类） K - Key（表示键，比如Map中的key） V - Value（表示值） ? - （表示不确定的java类型） 但是泛型的参数只能是类类型，不能是基本的数据类型，他的类型一定是自Object的 注意： 泛型不接受基本数据类型，换句话说，只有引用类型才能作为泛型方法的实际参数 2. 为什么要使用泛型？ 说到为什么要使用，那肯定是找一大堆能说服自己的优点啊。 # 泛型的引入，是java语言的来讲是一个较大的功能增强。同时对于编译器也带来了一定的增强，为了支持泛型，java的类库都做相应的修改以支持泛型的特性。 （科普：实际上java泛型并不是 jdk5（2004发布了jdk5） 才提出来的，早在1999年的时候，泛型机制就是java最早的规范之一） 另外，泛型还具有以下的优点： # 1.提交了java的类型安全 泛型在很大程度上来提高了java的程序安全。例如在没有泛型的情况下，很容易将字符串 123 转成 Integer 类型的 123 亦或者 Integer 转成 String，而这样的错误是在编译期无法检测。而使用泛型，则能很好的避免这样的情况发生。 # 2.不需要烦人的强制类型转换 泛型之所以能够消除强制类型转换，那是因为程序员在开发的时候就已经明确了自己使用的具体类型，这不但提高了代码...