Jekyll Bootstrap

页游微端开发技术

2014-04-15T00:00:00+00:00

几乎每个热门好玩,流水上千万的页游都会开发针对游戏相应的微端, 微端带来的仿端游操作上的体验和流畅度的上的优化是明显的,那么究竟微端的内部实现细节如何?

本期沙龙:

主讲: 岑远方

时间: 2014-04-15 20:00 - 21:00

地点: 5-2 会议室

内容概要:

微端是如何设计的？
微端是如何发布的？

打造个人完全自主的静态博客

2014-04-03T00:00:00+00:00

相信不少来到这个博客的同学都会想，是不是自己也可以搞专属个人的博客玩玩，写写东西,沉淀沉淀自己的所学所想。或许有的朋友已经有各大技术论坛的专有博客，个人空间。但是这些由于各个平台的一些限制，难免有些不自由。同时，繁多的选择，往往成为我们最终没有办法积累和坚持的根本原因。常常反思，也许我们可以试着通过自己的努力（其实通过后面我要介绍的，你会发现，其实要搞一个属于自己的完全个性化博客其实很简单）来构建一个自己的博客站点，个性化域名（完全自主），个性化设计，数据的保存，易于撰写和操作。。。心动了吗？那我们就开始这个有趣的有点Geek的互联网之旅吧。enjoy ^_^.

偏技术流的名词介绍

###Github Page### 如果有编程经验的童鞋,相信有不少都接触过或者听说过目前业界最大的开源代码分享社区github。即使没有听说过也不要紧，至少你现在听过了，只要你感兴趣，通过互联网相信你一定可以找到关于它的任何你感兴趣的信息。Gihub Pages 就是这个社区提供给所有将项目托管在其上的开发者一个可以自由，便捷创建项目主页的工具。我们接下来要搭建的博客就是基于这个伟大的工具来实现的。对于它的相信信息。这里不进行详细介绍，推荐一篇写的非常好的入门教程。搭建一个免费的，无限流量的Blog—-github Pages和Jekyll入门

项目特效资源压缩优化方案

2014-04-02T00:00:00+00:00

一个街机类的网页游戏,要做到画面精美,打击感流畅是很考验开发团队的技术实力的.在《街机武侠》项目中,我们美术童鞋在保证既有人物打击特效同时,又要考虑页游面临的资源过大加载困难的情况而做适度的资源压缩和减持.

效果如何?去体验下吧. 街机武侠

想知道其中内幕? 赶紧参加沙龙,或者查看我们后期的沙龙课件

本期沙龙:

主讲: 俞超

时间: 2014-04-01 20:00 - 21:00

地点: 5-2 会议室

内容概要:

什么是好的特效？
目前项目是如何减特效资源的？

按键精灵--解放你的双手

2014-04-01T00:00:00+00:00

我们都知道这样一个现状,一个NB的游戏背后肯定有一群人在开发一个针对这个游戏的NB外挂, 一个优秀的游戏可能因为一个外挂而终结它的光辉生涯,一个优秀的游戏也可能因为有外挂而最终走向巅峰.游戏世界的”攻”与”守”的战场上,从来就没有停止过硝烟. 呵呵,看到上面,你以为我们今天的沙龙主题是教你神乎其技的写外挂技术? 以为我们会演示NB哄哄的外挂操作? 你错了.我们要教你的仅仅是一款上手极易的可以作为外挂的轻量工具 – “按键精灵”.想了解更多,暂不剧透,大家一起来”开发者之夜” Happy 吧!

Jekyll Introduction

2014-03-27T00:00:00+00:00

This Jekyll introduction will outline specifically what Jekyll is and why you would want to use it. Directly following the intro we’ll learn exactly how Jekyll does what it does. ## Overview

What is Jekyll?

Jekyll is a parsing engine bundled as a ruby gem used to build static websites from dynamic components such as templates, partials, liquid code, markdown, etc. Jekyll is known as “a simple, blog aware, static site generator”.

Examples

This website is created with Jekyll. Other Jekyll websites.

What does Jekyll Do?

Jekyll is a ruby gem you install on your local system. Once there you can call jekyll --server on a directory and provided that directory is setup in a way jekyll expects, it will do magic stuff like parse markdown/textile files, compute categories, tags, permalinks, and construct your pages from layout templates and partials.

Once parsed, Jekyll stores the result in a self-contained static _site folder. The intention here is that you can serve all contents in this folder statically from a plain static web-server.

You can think of Jekyll as a normalish dynamic blog but rather than parsing content, templates, and tags on each request, Jekyll does this once beforehand and caches the entire website in a folder for serving statically.

Jekyll is Not Blogging Software

Jekyll is a parsing engine.

Jekyll does not come with any content nor does it have any templates or design elements. This is a common source of confusion when getting started. Jekyll does not come with anything you actually use or see on your website - you have to make it.

Why Should I Care?

Jekyll is very minimalistic and very efficient. The most important thing to realize about Jekyll is that it creates a static representation of your website requiring only a static web-server. Traditional dynamic blogs like Wordpress require a database and server-side code. Heavily trafficked dynamic blogs must employ a caching layer that ultimately performs the same job Jekyll sets out to do; serve static content.

Therefore if you like to keep things simple and you prefer the command-line over an admin panel UI then give Jekyll a try.

Developers like Jekyll because we can write content like we write code:

Ability to write content in markdown or textile in your favorite text-editor.
Ability to write and preview your content via localhost.
No internet connection required.
Ability to publish via git.
Ability to host your blog on a static web-server.
Ability to host freely on GitHub Pages.
No database required.

How Jekyll Works

The following is a complete but concise outline of exactly how Jekyll works.

Be aware that core concepts are introduced in rapid succession without code examples. This information is not intended to specifically teach you how to do anything, rather it is intended to give you the full picture relative to what is going on in Jekyll-world.

Learning these core concepts should help you avoid common frustrations and ultimately help you better understand the code examples contained throughout Jekyll-Bootstrap.

Initial Setup

After installing jekyll you’ll need to format your website directory in a way jekyll expects. Jekyll-bootstrap conveniently provides the base directory format.

The Jekyll Application Base Format

Jekyll expects your website directory to be laid out like so:

.
|-- _config.yml
|-- _includes
|-- _layouts
|   |-- default.html
|   |-- post.html
|-- _posts
|   |-- 2011-10-25-open-source-is-good.markdown
|   |-- 2011-04-26-hello-world.markdown
|-- _site
|-- index.html
|-- assets
    |-- css
        |-- style.css
    |-- javascripts

_config.yml Stores configuration data.
_includes This folder is for partial views.
_layouts This folder is for the main templates your content will be inserted into. You can have different layouts for different pages or page sections.
_posts This folder contains your dynamic content/posts. the naming format is required to be @YEAR-MONTH-DATE-title.MARKUP@.
_site This is where the generated site will be placed once Jekyll is done transforming it.
assets This folder is not part of the standard jekyll structure. The assets folder represents any generic folder you happen to create in your root directory. Directories and files not properly formatted for jekyll will be left untouched for you to serve normally.

Jekyll Configuration

Jekyll supports various configuration options that are fully outlined here: (https://github.com/mojombo/jekyll/wiki/Configuration)

Content in Jekyll

Content in Jekyll is either a post or a page. These content “objects” get inserted into one or more templates to build the final output for its respective static-page.

Posts and Pages

Both posts and pages should be written in markdown, textile, or HTML and may also contain Liquid templating syntax. Both posts and pages can have meta-data assigned on a per-page basis such as title, url path, as well as arbitrary custom meta-data.

Working With Posts

Creating a Post Posts are created by properly formatting a file and placing it the _posts folder.

Formatting A post must have a valid filename in the form YEAR-MONTH-DATE-title.MARKUP and be placed in the _posts directory. If the data format is invalid Jekyll will not recognize the file as a post. The date and title are automatically parsed from the filename of the post file. Additionally, each file must have YAML Front-Matter prepended to its content. YAML Front-Matter is a valid YAML syntax specifying meta-data for the given file.

Order Ordering is an important part of Jekyll but it is hard to specify a custom ordering strategy. Only reverse chronological and chronological ordering is supported in Jekyll.

Since the date is hard-coded into the filename format, to change the order, you must change the dates in the filenames.

Tags Posts can have tags associated with them as part of their meta-data. Tags may be placed on posts by providing them in the post’s YAML front matter. You have access to the post-specific tags in the templates. These tags also get added to the sitewide collection.

Categories Posts may be categorized by providing one or more categories in the YAML front matter. Categories offer more significance over tags in that they can be reflected in the URL path to the given post. Note categories in Jekyll work in a specific way. If you define more than one category you are defining a category hierarchy “set”. Example:

---
title :  Hello World
categories : [lessons, beginner]
---

This defines the category hierarchy “lessons/beginner”. Note this is one category node in Jekyll. You won’t find “lessons” and “beginner” as two separate categories unless you define them elsewhere as singular categories.

Working With Pages

Creating a Page Pages are created by properly formatting a file and placing it anywhere in the root directory or subdirectories that do not start with an underscore.

Formatting In order to register as a Jekyll page the file must contain YAML Front-Matter. Registering a page means 1) that Jekyll will process the page and 2) that the page object will be available in the site.pages array for inclusion into your templates.

Categories and Tags Pages do not compute categories nor tags so defining them will have no effect.

Sub-Directories If pages are defined in sub-directories, the path to the page will be reflected in the url. Example:

.
|-- people
    |-- bob
        |-- essay.html

This page will be available at http://yourdomain.com/people/bob/essay.html

Recommended Pages

index.html You will always want to define the root index.html page as this will display on your root URL.
404.html Create a root 404.html page and GitHub Pages will serve it as your 404 response.
sitemap.html Generating a sitemap is good practice for SEO.
about.html A nice about page is easy to do and gives the human perspective to your website.

Templates in Jekyll

Templates are used to contain a page’s or post’s content. All templates have access to a global site object variable: site as well as a page object variable: page. The site variable holds all accessible content and metadata relative to the site. The page variable holds accessible data for the given page or post being rendered at that point.

Create a Template Templates are created by properly formatting a file and placing it in the _layouts directory.

Formatting Templates should be coded in HTML and contain YAML Front Matter. All templates can contain Liquid code to work with your site’s data.

Rending Page/Post Content in a Template There is a special variable in all templates named : content. The content variable holds the page/post content including any sub-template content previously defined. Render the content variable wherever you want your main content to be injected into your template:

...
<body>
  <div id="sidebar"> ... </div>
  <div id="main">
    {{content}}
  </div>
</body>
...

Sub-Templates

Sub-templates are exactly templates with the only difference being they define another “root” layout/template within their YAML Front Matter. This essentially means a template will render inside of another template.

Includes

In Jekyll you can define include files by placing them in the _includes folder. Includes are NOT templates, rather they are just code snippets that get included into templates. In this way, you can treat the code inside includes as if it was native to the parent template.

Any valid template code may be used in includes.

Using Liquid for Templating

Templating is perhaps the most confusing and frustrating part of Jekyll. This is mainly due to the fact that Jekyll templates must use the Liquid Templating Language.

What is Liquid?

Liquid is a secure templating language developed by Shopify. Liquid is designed for end-users to be able to execute logic within template files without imposing any security risk on the hosting server.

Jekyll uses Liquid to generate the post content within the final page layout structure and as the primary interface for working with your site and post/page data.

Why Do We Have to Use Liquid?

GitHub uses Jekyll to power GitHub Pages. GitHub cannot afford to run arbitrary code on their servers so they lock developers down via Liquid.

Liquid is Not Programmer-Friendly.

The short story is liquid is not real code and its not intended to execute real code. The point being you can’t do jackshit in liquid that hasn’t been allowed explicitly by the implementation. What’s more you can only access data-structures that have been explicitly passed to the template.

In Jekyll’s case it is not possible to alter what is passed to Liquid without hacking the gem or running custom plugins. Both of which cannot be supported by GitHub Pages.

As a programmer - this is very frustrating.

But rather than look a gift horse in the mouth we are going to suck it up and view it as an opportunity to work around limitations and adopt client-side solutions when possible.

Aside My personal stance is to not invest time trying to hack liquid. It’s really unnecessary from a programmer’s perspective. That is to say if you have the ability to run custom plugins (i.e. run arbitrary ruby code) you are better off sticking with ruby. Toward that end I’ve built Mustache-with-Jekyll

Static Assets

Static assets are any file in the root or non-underscored subfolders that are not pages. That is they have no valid YAML Front Matter and are thus not treated as Jekyll Pages.

Static assets should be used for images, css, and javascript files.

How Jekyll Parses Files

Remember Jekyll is a processing engine. There are two main types of parsing in Jekyll.

Content parsing. This is done with textile or markdown.
Template parsing. This is done with the liquid templating language.

And thus there are two main types of file formats needed for this parsing.

Post and Page files. All content in Jekyll is either a post or a page so valid posts and pages are parsed with markdown or textile.
Template files. These files go in _layouts folder and contain your blogs templates. They should be made in HTML with the help of Liquid syntax. Since include files are simply injected into templates they are essentially parsed as if they were native to the template.

Arbitrary files and folders. Files that are not valid pages are treated as static content and pass through Jekyll untouched and reside on your blog in the exact structure and format they originally existed in.

Formatting Files for Parsing.

We’ve outlined the need for valid formatting using YAML Front Matter. Templates, posts, and pages all need to provide valid YAML Front Matter even if the Matter is empty. This is the only way Jekyll knows you want the file processed.

YAML Front Matter must be prepended to the top of template/post/page files:

---
layout: post
category : pages
tags : [how-to, jekyll]
---

... contents ...

Three hyphens on a new line start the Front-Matter block and three hyphens on a new line end the block. The data inside the block must be valid YAML.

Configuration parameters for YAML Front-Matter is outlined here: A comprehensive explanation of YAML Front Matter

Defining Layouts for Posts and Templates Parsing.

The layout parameter in the YAML Front Matter defines the template file for which the given post or template should be injected into. If a template file specifies its own layout, it is effectively being used as a sub-template. That is to say loading a post file into a template file that refers to another template file with work in the way you’d expect; as a nested sub-template.

How Jekyll Generates the Final Static Files.

Ultimately, Jekyll’s job is to generate a static representation of your website. The following is an outline of how that’s done:

Jekyll collects data. Jekyll scans the posts directory and collects all posts files as post objects. It then scans the layout assets and collects those and finally scans other directories in search of pages.
Jekyll computes data. Jekyll takes these objects, computes metadata (permalinks, tags, categories, titles, dates) from them and constructs one big site object that holds all the posts, pages, layouts, and respective metadata. At this stage your site is one big computed ruby object.
Jekyll liquifies posts and templates. Next jekyll loops through each post file and converts (through markdown or textile) and liquifies the post inside of its respective layout(s). Once the post is parsed and liquified inside the the proper layout structure, the layout itself is “liquified”. Liquification is defined as follows: Jekyll initiates a Liquid template, and passes a simpler hash representation of the ruby site object as well as a simpler hash representation of the ruby post object. These simplified data structures are what you have access to in the templates.
Jekyll generates output. Finally the liquid templates are “rendered”, thereby processing any liquid syntax provided in the templates and saving the final, static representation of the file.

Notes. Because Jekyll computes the entire site in one fell swoop, each template is given access to a global site hash that contains useful data. It is this data that you’ll iterate through and format using the Liquid tags and filters in order to render it onto a given page.

Remember, in Jekyll you are an end-user. Your API has only two components:

The manner in which you setup your directory.
The liquid syntax and variables passed into the liquid templates.

All the data objects available to you in the templates via Liquid are outlined in the API Section of Jekyll-Bootstrap. You can also read the original documentation here: https://github.com/mojombo/jekyll/wiki/Template-Data

Conclusion

I hope this paints a clearer picture of what Jekyll is doing and why it works the way it does. As noted, our main programming constraint is the fact that our API is limited to what is accessible via Liquid and Liquid only.

Jekyll-bootstrap is intended to provide helper methods and strategies aimed at making it more intuitive and easier to work with Jekyll =)

Thank you for reading this far.

Next Steps

Please take a look at []() or jump right into Usage if you’d like.

Git上线系统

2013-09-04T00:00:00+00:00

一、系统概述

该系统的开发主要针对页游开发采用分布式版本控制Git，而配合开发的一套针对代码进行版本控制，编译，上线的纯web化的流程系统。
系统主要由以下几大部分:
1. checkout（检出）：特定版本号的代码进行内外网的穿透,(页游开发均在内网进行,发布更新在外网)
2. compile(编译)：针对游戏服务端的发布，需要进行预编译。
3. tag(打包)：编译好的文件采用打包方式提高传输效率。采用SVN做打包文件的历史记录工具便于回滚和跟踪
4. push(推送)

二、上线系统操作流程

以下为上线系统一次完整的发布流程

[][img] [img]:/assets/img/opr-flow.png
##三、内部实现细节上线系统的操作分为游戏客户端资源的发布和服务端程序的发布.二者的的内部实现存在较大差异.如下针对各自的具体实现做详细介绍：
###客户端的发布：客户端的发布比较简单。只包含系统概述介绍的1，3，4。但在代码检出和打包部分,出于CDN资源同步效率及流量节省考虑。采用差异文件同步的思路。即生成上线文件过程中通过本次上线的版本与上次上线的版本做对比获取存在变化的差异文件,包括文件的A增,D删,M改.
<p class="text-info">注意：为实现CDN资源的预热和多版本（测试，联运，自营等）的切换。在CDN上存在多个资源目录如：</p> [/res_a][a]
[/res_b][b] [a]:http://pic1.webgame1.51img2.com/txdy_res_a/TXDY.swf [b]:http://pic1.webgame1.51img2.com/txdy_res_a/TXDY.swf 需要针对各个资源目录中的版本做差异化比对.
具体实现请参照代码. ###服务端的发布：服务端的发布由于需要通过上线系统来编译。因此相对较为繁琐。
编译前准备工作
<p class="text-warning">当baselib有更新时需要对 </p> net_manager更新:

#cd  net_manager 
#/usr/local/bin/cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS_RELEASE="-O3 -DNDEBUG" ./
#make && make install

utils更新:

#cd utils
#/usr/local/bin/cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS_RELEASE="-O3 -DNDEBUG" ./
#make && make install

接下来的操作,参照系统概述中介绍的步骤依次进行.具体实现请参照代码

四、Web部分介绍

简要介绍下上线系统的web部分实现（不涉及代码）。主要介绍下操作相关的实体及相应的库表。

ER图：
[][img] [img]:/assets/img/Diagram1.png

项目目录介绍:

|--/proj
	|--web # web部分代码
		|--www #入口
			|--sgit #接口入口
		|--src
			|--views #视图
				|--git
					... #git上线系统视图部分
			|--modules
				|--git.php #git上线系统前端部分控制器(单子创建,修改,流程,日志记录)
	|--scripts #操作脚本
		|--git #主要为通过git命令完成代码文件操作的脚本
			|--txdyServer.php #服务端的代码文件拉取,编译,打包操作
			|--txdyClient.php #客户端资源文件拉取,比对,打包操作
			|--svn.php #svn相关操作
			|--gitBase.php #srv.client的基类,完成git操作的初始化.
			|--gitapi.php #Git操作API
			|--git_ticket_real.php #实现接口

	|--git  #git上线系统的资源目录,所有通过git拉取的资源接在改目录
			|--tickets #上线单对应的上线文件
				|--server
					|--jj_server
						|--201309070001
						..
					..
				|--client
					|--jj_client
					..
			|--common #服务端编译是依赖的协议文件.每次编译时需要同步
					  #该目录文件.并将.h,.cc拷贝至服务端源目录.具体实现
					  #详见server的代码实现
			|--server #服务端的源码目录
				|--webgameJj-server
				..
			|--client #客户端资源目录

代码细节这里不过多赘述.有疑问请联系:zoezou

五、系统拓扑

[][img] [img]:/assets/img/publish-flow.png

由上图,可以看出,上线系统除了”上线系统”子模块外.还包括9.91(现:9.103)(同步系统[内网]).6.12(发布系统)
###同步系统同步系统主要实现上线单对应生成文件的同步,测试环境对应项目代码更新.
主要实现代码见: /opt/wwwroot/svn.51.com/

发布系统

发布系统控制相应版本代码最终发布上线.
其中包括客户端资源的CDN同步推送及版本切换,游戏服务端主程序资源并发推送更新,及服务的开,关,更新指令的集中化处理.

以上为上线系统的简要介绍,由于公司内部项目.没有开放源代码.有意向学习者可以与我联系@zoezou.或者在文章下面进行留言.大家一起交流探讨,共同进步. 相信 > 交流促进效率,分享创造价值. > –zoorz.com