ci

秉承MVC架构的思想，CI中的所有控制器都需要经过单点入口文件index.php（默认）来加载调用。也就是说，在默认情况下，所有CI开发项目的URL都形如以下这种形式： http://localhost/index.php/welcome 很显然，默认情况下，index.php在URL地址段中的存在一定程度上影响了URL的简洁和SEO的进行。我们可以通过下面本文介绍的方法来去掉这个讨厌的Index.php。 你或许已经注意到在CodeIgniter用户手册中，已经存在关于此问题的解决方法。但官方提供的这个.htaccess配置，并不是所有时候都能解决问题。下面经过笔者调试操作步骤供大家分享： 前提：服务器配置使用Apache作为Web服务器。 1、将以下配置信息复制并保存为.htaccess文件 （.htaccess文件放置在根目录下，即与application目录同级）， 默认情况下，index.php 文件将被包含在你的 URL 中： example.com/index.php/news/article/my_article 你可以很容易的通过 .htaccess 文件来设置一些简单的规则删除它。 ----------------------------------------------------------------- RewriteEngine on

（1）加载 htaccess 文件 # /etc/nginx/sites-available/dev.gingili.link （部分文件） server { listen 80; root /home/wwwroot/dev.gingili.link; #网站所在目录的绝对路径 index index.php index.html index.htm; #目录索引 server_name 'dev.gingili.link'; #网站的域名 include /home/wwwroot/dev.gingili.link/.htaccess; location / { index index.html index.htm index.php; #目录索引 } 重点是： include /home/wwwroot/dev.gingili.link/.htaccess; 让nginx 读取到 htaccess 文件 （2）开启 PATH_INFO 支持 location ~ \.php { # 不能有 $ fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_split_path_info ^(.+\.php)(.*)$; # 添加这行 fastcgi_param PATH_INFO

apache服务器下 首先配置apache支持rewrite，打开apache的配置文件，conf/httpd.conf ： LoadModule rewrite_module modules/mod_rewrite.so，把该行前的#去掉。 修改<Directory "自己项目目录"></Directory>内的AllowOverride 为All 在CI的根目录下，即在index.php的同级目录下，建立.htaccess，直接建立该文件名的不会成功，可以用其他工具创建editplus等。内容如下（CI手册上也有介绍）： RewriteEngine on RewriteCond $1 !^(index\.php|images|robots\.txt) RewriteRule ^(.*)$ /index.php/$1 [L] 如果文件不是在apache项目的根目录下，例如http://www.xxx.net/CodeIgniter/，第三行需要改写为RewriteRule ^(.*)$ /CodeIgniter/index.php/$1 [L]。我的index.php的同级目录下还有js文件夹和css文件夹，这些需要过滤除去，第二行需要改写为：RewriteCond $1 !^(index\.php|images|js|css|robots\.txt) 将CI中配置文件

From command line we have the entire MySQL server on hands (if we have privileges too of course) but we don’t have a overall overview, at this point the show table status command is every useful, or not?. This is what we get when run show table status in a standard 80×25 terminal screen: We can maximize the terminal window and decrease font size, but not all the time we need that lots of info. Some time ago I develop a stored procedure to get a global overview including functions and stored procedures. The result is pretty comprehensible: call tools.sp_status( database ()); + -- --------------

简介 从 Gitlab 8.0 开始，Gitlab CI 就已经集成在 Gitlab 中，我们只要在项目中添加一个 .gitlab-ci.yml 文件，然后添加一个 Runner ，即可进行持续集成。在介绍 Gitlab CI 之前，我们先看看一些 Gitlab CI 的一些相关概念。 Pipeline 一次 Pipeline 其实相当于一次构建任务，里面可以包含很多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。任何提交或者 Merge Request 的合并都可以触发 Pipeline 构建，如下图所示： +------------------+ +----------------+ | | trigger | | | Commit / MR +---------->+ Pipeline | | | | | +------------------+ +----------------+ Stages Stages 表示一个构建阶段，也就是上面提到的一个流程。我们可以在一次 Pipeline 中定义多个 Stages，这些 Stages 会有以下特点： 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始 只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功 如果任何一个 Stage 失败

入口文件 入口文件主要完成下列工作： 1) 指定 CodeIgniter 框架所在目录； 2) 定义 APPPATH 常量，指示应用程序文件根目录； 3) 载入 codeigniter/CodeIgniter.php 文件，启动框架。 codeigniter/CodeIgniter.php 文件 这个文件是 CodeIgniter 的基本文件，主要完成初始化 CodeIgniter 框架和启动应用程序两项工作。 1) 实例化 CI_Benchmark，这个类用于标记应用程序执行消耗的时间； 2) 载入应用程序的配置文件 require(APPPATH.'config/config'.EXT); 3) 实例化 CI_Config，这个类用于将数组封装为可以操作的配置服务； 4) 实例化 CI_Router，这个类用于分析 URL 请求，确定要执行的控制器和动作； 5) 实例化 CI_Output，这个类提供输出内容的缓存和检查服务； 6) 通过 $OUT->_display_cache($CFG, $RTR) 尝试输出缓存内容，如果成功，则结束程序运行； 7) 判断控制器类定义文件是否存在。如果不存在则通过 show_404() 显示错误信息； 8) 实例化 CI_Input，这个类提供对 $_GET、$_POST 的访问手段，并封装了一些过滤方法； 9) 实例化 CI_URI

最近一直想做一个技术类的新闻站点，想做的执行效率高些，想用PHP做，一直纠结于用纯PHP做还是用CI或者THINKPHP。用纯PHP效率高，缺点n多，比如安全方面、构架方面等等等等；用CI、thinkPHP的话这些需要考虑的就少些，但是怕效率方面差得太多。后来就想先测测吧，如果差得太多，就自己写个“框架”，满足自己的需求即可的框架。 CI版本是2.1.3,thinkphp用的是3.1。 因为大多数站点所做的事情就是查询数据库，因此此次的测试着重于数据库查询并显示。测试的数据库是dede的sys_enum，631条数据。目标就是查询出这些数据并显示到页面上计算消耗时间。 =========================================================================== 1. 对于纯PHP ，思路是在开始时记一下毫秒数，结束时记一下毫秒数，相减后得结果。纯PHP简单，直接贴代码： <?php $begin=microtime(); $begin=microtime_float($begin); ?> <?php function microtime_float($time) { list($usec, $sec) = explode(" ", $time); return (((float)$usec + (float)$sec)

2019年08月09日，上海受台风利奇马的影响，晚间狂风大雨。 临下班，合作渠道WB在微信群里报告线上生产事故问题：赶快扒日志看记录，日志显示一切正常，看不出bug在哪里，WB声称并未接收到我方CI的回调请求。晚七点多，肚子已经饿了，给WB说，看日志CI没啥问题，先撤了。 在出公司大楼经过一个拐角的时候，隐隐感觉这情形代码里的配置项会不会有问题，心里很是忐忑，冒雨又折回。重新打开电脑，再捋一遍代码的时候，bug像一道匕首直刺心头：卧槽，这个路径竟然还是测试环境 的路径！项目组是公司敏捷开发团队，每周五都会有生产版本发布，赶快给负责版本控制的同事打招呼，等一下，搭个顺风车。 在确定了配置路径有问题之后：亟待明确的是服务间调用是走内网还是走外网，要不要NG转发，走不走esb，是不是要申请通信权限。简单描述一下WB的该次请求：WB请求CI的NG--------》NG转发到CI的Mule服务----------》Mule服务调用Gateway----------》Gateway转发至应用微服务Application ---------》Application服务响应之后执行异步回调Mule服务---------》Mule服务请求WB接口地址 。中间涉及的防火墙和权限就暂且忽略，目前的问题点是：Application服务响应之后执行异步回调Mule服务，这个Mule服务内部接口地址规范是什么

概述 之前学习了一位半加器与一/四位全加器的相关知识，接着学习超前进位加法器加深认识 八位级联进位加法器 设计文件 采用硬件行为方式描述八位全加器 123456789101112131415161718192021222324252627282930313233343536373839404142434445 module qjq(co,sum,a,b,ci); input[7:0] a,b; input ci; output[7:0] sum; output co; reg[7:0] sum; reg co; reg[7:0] G,P,C; //中间变量，分别是生产函数、传递函数、和进位函数always @(a or b or ci) begin G[0] =a[0] & b[0]; //生产函数，加数相与,产生进位 P[0] =a[0] | b[0]; //传递函数，如果a或b有不为0，则将进位输入传递 C[0] =ci; //最后位的进位输入，初始化位ci sum[0] =G[0]^ P[0] ^ C[0];//输出数据 G[1] =a[1] & b[1]; P[1] =a[1] | b[1]; C[1] =G[0] |(P[0] & C[0]);//c=ab+(a+b)ci=G|(P&ci) sum[1] =G[1] ^ P[1] ^ C[1]; G[2] =a[2] &

在互联网时代，对于每一家公司，软件开发和发布的重要性不言而喻，目前已经形成一套标准的流程，最重要的组成部分就是持续集成（CI）及持续部署、交付（CD）。本文基于Jenkins+Docker+Git实现一套CI自动化发布流程。 一、发布流程设计 工作流程： 开发人员提交代码到Git版本仓库； Jenkins人工/定时触发项目构建； Jenkins拉取代码、代码编码、打包镜像、推送到镜像仓库； Jenkins在Docker主机创建容器并发布。 环境规划如下： 角色 IP Jenkins/Docker 192.168.0.217 Docker 192.168.0.218 Git/Registry 192.168.0.219 操作系统：CentOS7.4 二、部署Git仓库 # yum install git -y 创建Git用户并设置密码 # useradd git # passwd git 创建仓库 # su - git # mkdir solo.git # cd solo.git # git --bare init 访问创建的这个仓库 # git clone git@192.168.0.212:/home/git/solo.git 三、准备Jenkins环境 Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于代码编译、部署、测试等工作。