5、6 月份的 10 个最佳 jQuery 插件

1) jQuery Popeye jQuery.popeye 这个插件能够将一组无序的图片列表转换成一个简单的相册。当点击图片时将以Lightbox风格放大图片。图片展示框提供向前/向后控制并能够为每一张图 片添加备注说明信息。jQuery.popeye能够根据图片大小自动调整展示框的高度和宽度。 2) jQuery MB Gallery 这是一个全功能的相簿应用,带导航条、缩略图和自动大小调整的相框。 3) Topup TopUp 是一个跨浏览器支持的 JavaScript 库,用于创建弹出式对话框以显示图片和网页,类似 ThickBox和 LightBox。TopUp 使用的是 jQuery 和 jQuery UI 库来保证兼容各种浏览器。当然 TopUp 还是可以跟Prototype 一起工作。 4) Pirobox 采用jQuery开发的Lightbox控件。能够根据浏览器窗体大小自动调整展示图片大小。提供向前/向后控制链接。动态加载图片效果。易于定制。 5) Fancy Zoom FancyZoom采用缩放效果来展示图片或任意HTML页面,不需要另外开启页面来载入图片,其效果在Apple Mac的官方网站中也有。 6) Canvas Slide Show 7) SideWays jQuery 8) Galleriffic Galleriffic是一个用于创建快速展示相册中照片的jQuery插件。图片既可以以幻灯片的方式查看,也可以手动点击缩略图查看。Galleriffic还支持分页,从而使得它能够展示更多的图片。 9) ColorBox ColorBox是一个基于jQuery 1.3 的轻量级,自定义灯箱插件,功能非常强大,支持图片,图片组,ajax,inline和iframed内容,灯箱样式完全由用户控制,可自定义CSS样 式,不需要改写ColorBox库文件就能重写展示效果设置,支持加载预处理提示等等,效果图如下: 在线演示:http://runjs.cn/detail/hjor2zox 10) YUI 转自:http://www.oschina.net/news/41500/10-best-jquery-plugins-with-code-of-may-and-june-2013

龙生   18 Jun 2013
View Details

我的技术心病

上图为本文的作者Sasha Goldshtein,他是SELA Group公司的首席技术官,他是Microsoft C# MVP(最有价值技术人员),是《Introducing Windows 7 for Developers》 (Microsoft Press出版, 2009) 和 《Pro .NET Performance》 (Apress出版, 2012)两书的作者。他是一位多产的博客作家,是大量的培训教程的作者,内容包括并行编程、Windows Internals, .NET Debugging, 和 .NET 性能等。他的顾问工作主要围绕分布式架构和高性能系统。 我发现,对我来说,使用一种新语 言,新技术,新框架,最让我有压力的事情是,我在使用它们时不能完全明白它们的实现原理。我每周都要阅读数百篇关于讨论诸如各种JavaScript扩 展、新的iOS应用框架,新的基于Windows Azure的SaaS等的博客文章。很显然,如果只是使用一些技术或采用一种框架来满足需求,这对于我通常不是很难的事情。问题是,如果我并不理解一个东 西的工作原理或实现方法,我不能把它归入我已经掌握的知识。这也是“Not Invented Here(非我造不用)”毛病的一种表现吧,不同的是我并不是想真正的写出我自己的框架;我只是想做到我有能力写出它们。下面是我最近的一些例子。 2011 年末,我开始学习Node.js,2012年间,我基于Node、Express以及其它很多Node模块,实现了数个私人或商业产品。我开始使用 Node时非常犹豫,直到我完全掌握了它的基本原理——事件循环,异步无处不在的属性——这使我掌握了如何实现“类似Node”之类东西的知识。有一段时 间我甚至想写利用新的C#提供的async/await实现一个Node类似的HTTP框架,但最后放弃了,因为网上像这样的东西很多,比如 ASP.NET MVC控制器等,只是不通用。 还有一个事情就是,某种程度是,我仍然有点“恐惧”WPF(Windows用户界面框架)。 我谈不上是特别喜欢客户端开发,但从感受层面上,从各种表现上,WPF是一种比XAML更有吸引力的框架。并不是说WPF很复杂难用:我理解它的一些基本 实现原理,比如数据绑定,风格,资源,以及数据模板,这些足够让我实现简单的桌面应用或简单的Windows8和Window Phone应用。是WPF的深度和广度让我困惑:我现在的做法是否是最好的做法?这些XAML表达式究竟是如何在这样的数据环境和属性依赖条件下工作的? 是否我应该把这段代码放到一个单独的动作或控制里?…我不是没努力过:我至少读了3本关于WPF的书,总页数超过1500页,但它们并没有给我多大帮助。 结果是,在潜意识里,我尽量避免基于XAML的框架,因为我不知道如何实现它。而可笑的是,我对一些“轻量级”的客户端技术,包括MFC,Windows Forms,Android,以及iOS,都非常有信心,而对于XAML,对于它的那些相对高级的东西,已经在我的心里留下了畏惧的条件反射。 说 一些我感到非常有自信的东西,我对那些利用反射技术的东西,从序列化校验到代码生成,我都感觉很轻松。这些属性,这些反射,10年前当我做一个大.NET 项目时就根深于我的脑子里,从那时起它们对于我就是一个非常强大的工具。我想这归功于我能理解它们这些对象如何存放在内存里,知道.NET的原信息是如何 组织的。事实上,我差不多同时也就对其他语言和框架里的反射机制很清楚了:例如,当我在开发非官方的Adnroid SDK时,第一直觉就是想写自己的JSON序列化工具,而不是利用第三方类库。之后虽然证明这并不是最好的做法,但我能够在2小时内让我的程序支持所有类 型的WAMS要求。 最后一个例子,我对新语言有很大的心理压力,尤其是当这种语言不只是从一种语言编译成另外一种语言。换言之,我对像 TypeScript或CoffeeScript这类语言没压力,我可以清楚了理解这种原代码如何编译成JavaScript,如何一种新语法变成同种功 能语法的一种简写。但是,对于一些“新物种”语言,例如Objective C,引起我脑海里一大堆问号。并不是它的括弧语义给我造成麻烦,而是这种语言的原理,“how”。Objective C语言的对象是如何分配内存的?方法是如何调度的?如果方法可以被过载,还能通过名称进行动态调度吗?编译器是如何动态管理内存的?(没错,引用数计数 ——但问题远比这几个字复杂)。同样的事情也发生在Python这样的语言上:我可以使用Python开发脚本,编写模块,甚至和C语法风格的DLL交 互,但我对这种动态语言里如何存放一个属性,如何类型化,没有一个清晰的画面。 作为总结,我希望所有的教材都提供一个“工作原理”的章节, 来告诉我我如何能实现这种语言、技术和框架——我自己。至此,我希望这篇文章解释清楚了我为什么喜欢对技术原理刨根问底、喜欢自己去实现它们。归根结底的 原因是,我喜欢对系统、框架、语言做全面的理解;也许我只需要对某个系统修改一个bug或做性能调优,但最终结果是,我要去知道它是如何运行的,否则,它 会变成我的一个心病,拖得越久我会越痛苦。 [英文原文:Using Something You Can't Implement Yourself ] 转自:http://www.oschina.net/news/41512/using-something-you-cant-implement-yourself

龙生   18 Jun 2013
View Details

WAMS

WAMS (Wide Area Measurement System)  广域监测系统 电网广域监测系统采用同步相角测量技术,通过逐步布局全网关键测点的同步相角测量单元(PMU),实现对全网同步相角及电网主要数据的实时高速率采集。采集数据通过电力调度数据网络实时传送到广域监测主站系统,从而提供对电网正常运行与事故扰动情况下的实时监测与分析计算,并及时获得并掌握电网运行的动态过程。 WAMS作为电网动态测量系统,兼顾了SCADA系统和故障录波系统的功能。其前置单元相量测量装置PMU能够以数百Hz的速率采集电流、电压信息,通过计算获得测点的功率、相位、功角等信息,并以每秒几十帧的频率向主站发送。PMU通过全球定位系统(GPS)对时,能够保证全网数据的同步性,时标信息与数据同时存储并发送到主站。因此,WAMS能够使调度人员实时监视到电网的动态过程。 转自:http://baike.baidu.com/view/5344299.htm

龙生   18 Jun 2013
View Details

我现在是这样编程的

我在做什么 曾经,我试过接到一些需求。一眼带过后,脑袋马上随着高昂的斗志沉溺在代码的世界中 ,马不停蹄地敲着键盘直到最后测试的完成。我从思绪中恢复过来,乍一看自己写的功能,和需求差了十万八千里,我TM都在干嘛? 除此之外,我还见过类似的很好笑的事情。有一个程序员,经理提了需求,然后他在那里折腾了一天。结果不但没做出来,而且和实际需求都是完全搭不上调。经过询问发现,他不知道经理说了什么,也不知道自己到底在做什么。 代码的世界可能是昏天暗地的,但是我们的思维不能这样随之混乱,否则一切都会前功尽弃。所以我现在编写程序的时候,经常会想一下:我要做什么,我在做什么。更好的方法是把详细需求落实到文档,并时刻核对文档。 大局为重 2-8法则告诉我们,一个项目核心的功能只有很少,其它大部分都是对核心功能辅助或增强的。但当任务分发下来,我手头总有一些自己很想开发的模块,不过它们不属于那20%。我以前经常会在这些感兴趣的模块上花费很多时间和精力。 结果项目快要到上线期限,主要的功能却没开发完成,其它一些不起眼的功能却做得很好,但为此项目不得不延期了。如果反过来,只要对整体功能预期不会有太大偏差,可以将就的先上线。重要一点是:即使功能还有遗漏,但项目可以上线了,老板自然不会太追究,自己工作也能图个安心。如果不知道那些功能模块是最重要的,先问问经理。 人总是喜欢做一些自己感兴趣或者有挑战的事。不过在这方面,为了项目和团队着想,应该尽量压制这种诱惑。 性能永远不是优先考虑的问题 我从来不会一开始就考虑性能问题。如果项目成本很低,甚至到项目结束时,如果没有感觉到明显的性能问题,也不会去管。要知道现在已经不是DOS的年代,CPU的计算能力很高,但成本很低了。重要一点是,如果只针对提升性能对代码做改动,很容易破坏代码的复用性和可维护性。而返过来,提高了代码的复用性和可维护性,则很容易提高性能。 下面有一个PHP的代码实例,功能是帮助用户重置密码(代码为了简单说明问题,请不要太在意一些无关的细节) requestResetPassword是接收用户重置密码的请求并且做了相应的检查。为了更好的复用性,我将重置密码的操作单独分配到一个新的resetPassword的函数,更改完密码的后再调用sendEmail向用户发送一封通知邮件。 现在问题是,这三个函数都同时使用checkUserExists这个函数来检查用户不存在,数据库查询了三次,这样带来了一些额外的开销。 如果要去掉三者之间任意一个checkUserExists,看上去是可能的。但是如果之后有某些功能要调用resetPassword或者sendEmail,用户不存在时,系统可能会发生错误。 还有一个解决方法是,将resetPassword的逻辑写到requestResetPassword里,再过一点,把sendEmail的逻辑也写进去。这样函数调用减少,数据库查询也变成一次了,性能得到了提高。但是重置密码和发送邮件的功能将不能得到复用,并且违背了单一责任的原则,代码复杂度也提高了。 不过,因为函数分离和复用性都很好,如果实际性能受到影响,可能考虑用缓存的方法减少数据库查询,我改动了它们共用的checkUserExists函数: 也可以用同样的方法改动getUserInfo函数。 这里可以看到,当代码的复用性提高时,想提高性能是很简单的,性能的瓶颈也很容易被发现和修改。 尽管这个例子对性能影响还不够大,还有一些影响更大的,比如说遍历,我可能为了复用而将遍历封装到一个函数中,并且多次使用它。这些开销对我的项目根本没有预想中那样有太大的影响,或者说是微乎其微的。所以我更愿意把时间花在如何提高代码的复用性和维护性方面,而不是纠结于浪费多这一点性能。实际性能如果真的达不到要求,也可以权衡增加硬件配置。 名字长一点好 函数名和变量名等除了给机器看,也要给人看的,有时一个简单直接的好名字实在是很难想,这时不妨用长一点的名字更好。可读性更好: 我见过一些代码,由于简单写过多,整遍代码很多都是4个字母或以下的,可读性非常差,当然不排除是为了偷懒。 但如果想有更多的时间腾出来偷懒,不应该在这上面玩小聪明,否则这时我现在应该在思考前几天的代码是在写什么。 什么?短名字会让代码执行得更快? 那证明给我看,如果真的快,快了多少? 自说明代码很重要,但注释同样重要 代码本身可以说明问题的确是很棒的,但并不是说注释不重要,有时候我更喜欢先看注释,因为它总比我看代码更快的了解这程序是做什么的。 如果我把本文前面说性能的例子去掉注释,哪个能让你更快了解代码的意图?或者说,你更愿意看哪个? 所以,即使代码本身很清晰,但是加上注释的话,可读性也能提高很多! 适当抽象 编程就是为了解决实际中的问题,在思考如何编码的时候,把问题抽象到一定的高度去思考,更容易把握问题所在。不过更多时候,我发现从代码抽象到现实的例子是有一定难度的,同时我也相信,编程高手也是抽象高手,他们很容易把问题反映到真实生活中去。 不过如果经常留意和思考生活中的细节,会提升自己的抽象能力。 举一个螺丝刀的例子,如果叫你造一个螺丝刀,你会做成什么样子?我这里有三把不同的螺丝刀: 显然第一种螺丝刀是最简单的,比较中规中矩。 第二种螺丝刀中间可以旋转刀柄,让刀柄和刀头成90度,这样的设计让拧螺丝更加轻松。 第三种螺丝刀则可以更换刀头,如果以后有其它类型的螺丝,则只要造一个适合这种螺丝的刀头就可以了。 那反映到编程中的问题,如果项目要增加一个工具类库。 第一种方法,可以直接把类库的所需功能写出来就可以了。 第二种方法,不但把类库写出来,而且针对项目的一些情况做特殊改进,使得在这个项目中更好用。 第三种方法,根据类库的特性,把公共部分的逻辑做成接口,特殊的部分分离出来单独实现,如果以后要增加相同类型的类库,则实现特殊部分的逻辑,然后接入接口即可。 但是在抽象的时候,要避免不合理的抽象,有时也可能造成过渡设计,现在只需要一种螺丝刀,但你却把更多类型的螺丝刀都做出来了(而且还是瑞士军刀的样子。。): 一致性 团队开发中,可能每个人的编程风格都不一样,拿花括号来说,有些人喜欢和代码在同一行,而有些喜欢独自一行 命名风格也都不一样,比如说声明变量接收一个函数返回的数据,有些喜欢用result,有些喜欢用data。 它们可能都很好,不过在团队开发中,尽量统一用同一种风格能够很好的减少交叉开发的成本。 将错就错 面对项目一些无关紧要的分歧或错误,应该要接受和理解。承接上面的问题,如果团队中已经有人大量用了data的变量命名,但你认为result的更符合当前状况的描述。这种情况,我优先选择data命名,因为如果再使用result的话,会破坏项目的一致性,对开发没有任何好处。 这只是很少的一方面,如果项目规范没有很好的落实,实际工作中会有大量的一致性问题,必须靠团队每个人的决心和责任心去把它做好。通常,加入一个正在开发中的项目,编写功能前,我都会首先看项目之前的类似的代码,并尽量模仿他们的写法。不过,如果有明显的错误,应该及时指出和修正。 只要坚持把一致性做好,很多方法会成为团队甚至业界的标准,即使它们不是最好的,但是有什么关系呢? 适当休息 编程的时候如果没有思路或者感到混乱,到外边休息10分钟,或者看一下风景,让脑袋清醒一下是很好的。这招很管用,亲测。 至少把代码完整运行一次 有时函数的逻辑过于简单,以至于会认为这个不可能发生错误,但事实上最容易发生错误的通常就是这些代码,常见的单词拼写错误,参数错误,还有一些意料之外的问题。所以无论什么情况,我都会把代码完整运行一遍。 当然更好的做法是用一些系统的测试方法,比如说单元测试。 编程不是艺术 从一开始,编程语言的出现和发展,都是为了解决现实生活中的问题,包括它自身产生的问题。 面向对象、设计模式的出现,是用来解决编程语言自身带来的可读性和维护性等问题,而不是为了让编程语言上升到艺术的层面。尽管编程中有‘优雅’一词,但我更认为它只是用来形容代码更容易让人读懂和维护。 我拒绝一切看起来很‘优雅’,却不能为编程工作带来一点好处的代码。如果你喜欢玩弄语言,应该去当作家。 甘于平凡 程序员真的很高傲,在我接触过的人中,包括我自己也是。我以前经常对一些简单的代码感到不屑,而总想在项目中写一些犀利的代码,让人看起来很NB,但结果总是和想象差太远,代码总是写的很差,逻辑也不够清晰。归根到底,是我带着这样的思想去写代码,而忽略了编程的根本:解决问题。现在我改掉了这个坏毛病,以解决问题为目的去编程,以简单为主。出乎意料的是别人有时会对我说,这里的代码写得很棒。 踏实的做事,会有意想不到的收获。 承认错误 不要怀疑,当别人用自己的程序或者代码无法运行时,首先考虑是否是自己的逻辑哪里有问题。一来别人会觉得我谦虚,二来实际大多数情况的确是自己的问题。 有原则,有决心 做任何事情都坚持原则,并有决心是最好的。有很多道理我们都明白,但经常做不到,没有任何人能帮到自己,未来也是自己争取的。 所以,如果知道什么是好,就尽量去做,什么是不好,就尽量避免。 即使是在公司面对经理和领导,也要坚持自己的做法,一些不合理的需求应该指出或拒绝。我还年轻,大不了换一家公司,而不愿意做一个受欺压的码农。 我在做什么 文章写完了,现在来回想一下,我是在分享自己现在编程的一些习惯,总算没偏离开始的主题。本文的思想都是来自实际工作和一些书籍,想了解更多的话,推荐阅读《整洁代码之道》《代码大全》《重构》这几本书。 如果你有一些认为好的编程方法,不妨拿出来和大家分享一下。 转自:http://my.oschina.net/u/867608/blog/138002

龙生   17 Jun 2013
View Details

UML建模工具中EA和Rose的比较

本节和大家一起看一下UML建模工具比较,主要介绍了UML建模的特性中EA和Rose的UML图建模比较,EA和Rose的UMLProfile比较两部分内容,相信通过对比我们能够找到更加实用的建模工具,下面就让我们一起来看一下UML建模工具的比较吧。 UML建模工具比较 自从1997年正式发布UML以后,大量商用UML建模CASE工具粉墨登场。这样为我们提供了许多的选择,同时也要求我们在选择正确的UML建模工具以更好地适应我们业务和软件应用程序开发需求,达到最好的投资回报率(ROI)方面做大量的调查。在这篇文章中,我们将比较两款CASE工具的UML建模能力、双向工程特性和项目生命周期支持:SparxSystems的EnterpriseArchitect(EA)专业版V.3.51和IBMRational的RationalRose企业版V.2002。 为什么我们需要UML建模CASE工具? 今天,系统的构建变得越来越复杂,UML建模CASE工具为项目相关人员(如,项目经理,分析员,设计者,构架师,开发者等)提供了许多的好处。UML建模CASE工具允许我们应用规范的面向对象分析和设计的方法与理论,远离纠缠不清的源代码,达到构建和设计变得更直观,更容易地理解与修改的层次。在大型项目中,使用CASE工具更重要。通过使用CASE工具: ◆通过用例模型,业务/系统分析可以捕获到业务/系统需求。 ◆设计者/构架师所作的设计模型能在不同层次的同一层内清晰表达对象或子系统之间的交互(典型的UML图如类图和交互图)。 ◆开发者能快速地将模型转变为一个可运行的应用程序,寻找类和方法的子集,以及理解它们如何交互。模型被看作是蓝图和构建系统的最终手册。同样,建模也就是一种从高层并以适当的形式来考虑一个设计的表述和理解它怎样运行的能力。出于这些动机,UMLCASE工具以及对应的方法论为我们提供了一种因系统太复杂而不能理解下层源代码的描述系统的方法,同时允许我们更快更便宜地开发正确的软件解决方案。当然,要考虑CASE工具在UML建模能力,项目生命周期支持,双向工程,数据建模,性能,价格,可支持性,易使用性等方面的不同。这篇文章将探索Rose与EA在UML建模,项目生命周期支持以及双向工程领域的相同点和不同点,希望能帮助你在你的项目中选择正确的工具。 UML建模工具特性 UML标准由三部分组成,即:构造块(如对象,类,消息),构造块间的关系(如关联,泛化)和图(如,活动图)。UMLprofile使用UML可扩展性机制扩展标准UML符号,即,构造型,标注值和约束。EA专业版V.3.51和RationalRoseV.2002.05都支持UML1.4 九种图中的八种标准UML图-用例图,类图,序列图,协作图,活动图,状态图,实现图(组件)图,部署图,和几种UMLProfiles.如果需要,对象图可以使用协作图来创建。不同点仅仅存在于创建UML图(表1)和扩展UMLprofiles时所支持的一些特性。 表1.UML建模工具中EA和Rose的UML图建模比较 EnterpriseArchitect有一个通用的UMLprofile机制用来加载和运行不同的Profiles。EnterpriseArchitect为UMLprofiles指定一个特定格式的XML文件。而在RationalRose中却需要生成一个附加项。 表2展示了在EA和Rose中UMLprofiles的可用性。 表2.UML建模工具中EA和Rose的UMLProfile比较 【编辑推荐】 五个免费UML建模工具推荐 如何选择一种UML建模工具 UML建模工具Apollo for Eclipse 1.1发布 UML建模工具UMLGraph 4.3 发布 UML建模工具比较

龙生   15 Jun 2013
View Details

Asp.net MVC2中使用Ajax的三种方式

      在Asp.net MVC中,我们能非常方便的使用Ajax。这篇文章将介绍三种Ajax使用的方式,分别为原始的Ajax调用、Jquery、Ajax Helper。分别采用这三种方式结合asp.net mvc去实现一个史上最简单的留言板。     首先看一下原始的Ajax的调用的      定义CommentController,代码如下:

    在Asp.net MVC中添加一个custom_ajax.js,加入下面使用ajax的脚本代码,调用AddCommentServer方法。

    在View中引入此脚本,创建一个简单的表单,并添加触发的代码:

    添加下面脚本:

 

   效果:与方式一效果一样

    1、首先了解一下Ajax Helper下面四种方法。         a、Ajax.ActionLink():它将渲染成一个超链接的标签,类似于Html.ActionLink()。当它被点击之后,将获取新的内容并将它插入到HTML页面中。         b、Ajax.BeginForm():它将渲染成一个HTML的Form表单,类似于Html.BeginForm()。当它提交之后,将获取新的内容并将它插入到HTML页面中。         c、Ajax.RouteLink():Ajax.RouteLink()类似于Ajax.ActionLink()。不过它可以根据任意的routing参数生成URL,不必包含调用的action。使用最多的场景是自定义的IController,里面没有action。         d、Ajax.BeginRouteForm():同样Ajax.BeginRouteForm()类似于Ajax.BeginForm()。这个Ajax等同于Html.RouteLink()。     这个例子中使用Ajax.BeginForm(),下面具体了解Ajax.BeginForm()的参数。看下面代码

    actionName:AddComment(action的名字)     controllerName:CommentController(Controller的名字)     ajaxOptions:          HttpMethod:Ajax的请求方式,这里为POST           UpdateTargetId :Ajax请求的结果显示的标签的ID,这里为comments          InsertionMode:将Ajax结果插入页面的方式,这里将ajax的结果放置到comments的后面 2、实现:     在CommentController中添加IndexAjaxHelp方法。

      根据IndexAjaxHelp生成View表单IndexAjaxHelp.aspx,定义表单:

    要在此View中添加下面两个脚本文件:

   这样就行了,我们发现比用Jquery方便很多,但是使用Jquery将灵活很多。      3、效果:和方式一样。 总结:本文非常的简单,在asp.net mvc中实现了3中ajax的调用方式,实现了一个最简单的留言板程序。推荐使用Jquery和Ajax Helper这两种。Ajax Helper使用非常简单,Jquery比较灵活。 更新:三种方式都实现了一个最简单的留言板程序 参考:     ASP.NET MVC 2 In Action     Pro ASP.NET MVC 2 Framework, Second Edition   代码:http://files.cnblogs.com/zhuqil/AjaxDemo.rar   作者:朱祁林出处:http://zhuqil.cnblogs.com本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。  

龙生   14 Jun 2013
View Details

生成缩略图

龙生   06 Jun 2013
View Details

Normalize.css

Normalize.css 是一个可以定制的CSS文件,它让不同的浏览器在渲染网页元素的时候形式更统一。 官网:http://necolas.github.io/normalize.css/

龙生   06 Jun 2013
View Details

CSS 框架 Yahoo Pure

Pure 是来自雅虎的 CSS 框架,使用 Normalize.CSS 无需任何 JavaScript 代码。框架基于响应式设计,提供多种样式的组件,包括表格、表单、按钮、表、导航等。标识使用非常简单,整个框架非常轻量级,压缩后只有 5.7k。 官网:http://purecss.io/ 设计器:http://yui.github.io/skinbuilder/?mode=pure

龙生   06 Jun 2013
View Details

PHP中一些通用和易混淆技术点的最佳编程实践

我们使用的是哪个 PHP 版本? 带有 Suhosin-补丁的PHP 5.3.10-1ubuntu3.6, 安装于 Ubuntu 12.04 LTS. PHP如同是网络世界的百年老龟。它的外壳上刻有一个丰富的,令人费解的,粗糙的历史。在一个共享主机的环境下,它的配置可能会限制你能做什么事情。 为了保留一丝明智,我们需要只专注于一个版本的PHP。截至2013年4月30,该版本是 带有Suhosin补丁的PHP5.3.10-1ubuntu3.6 。如果你使用apt-get从一个Ubuntu12.04 LTS服务器来安装PHP的话,你所得到的版本就是这个。换句话说,许多人在默认情况下已经很明智地使用了它。 您可能会发现本文这些解决方案能工作于不同或更旧版本的PHP。如果是这样的话,就要由你来研究在这些旧版本中的细微错误或安全问题的影响了。 保存密码 使用 phpass 库计算密码的哈希值进行比较。 用 phpass 0.3 进行的测试。 散列化是在把用户密码保存进数据库之前对其进行保护的标准方法。许多常见的散列算法,如MD5,乃至SHA1,用于存储密码都是不安全的,因为黑客可以使用这些散列算法轻松破解密码。 要散列化密码最安全的方法是使用bcrypt算法。开源的phpass 库用一个易于使用的类来提供这个功能。 例子: view source print? 01 <?php 02 // 包含phpass库 03 require_once('phpass-0.3/PasswordHash.php'); 04 05 // 初始化散列器为不可移植(这样更安全) 06 $hasher= newPasswordHash(8, false); 07 08 // 计算密码哈希值。$hashedPassword 将会是一长为60个字符的字符串. 09 $hashedPassword= $hasher->HashPassword('my super cool password'); 10 11 // 你现在可以安全地保存$hashedPassword到数据库中! 12 13 // 通过比较用户输入内容(产生的哈希值)和我们之前计算出的哈希值,来判断用户是否输入了正确的密码 14 $hasher->CheckPassword('the wrong password', $hashedPassword); // 返回假 15 16 $hasher->CheckPassword('my super cool password', $hashedPassword); // 返回真 17 ?> 陷阱 很多来源会建议你在计算密码的哈希值之前先给密码加点“作料”。这是个好主意,phpass已经利用HashPassword() 函数中的一部分代码来为你给密码加了作料。 这就意味着你并不需要自己再亲自做这个了。 进一步阅读 […]

龙生   04 Jun 2013
View Details
1 352 353 354 410