编译程序时遇到了这个错误,点击详细信息,原来是ambiguous,xcode在keychain找到了多个证书,一个在system中,一个在默认的login中。Google了一下,有不少开发者都遇到这个问题了,对于我来说,其实是由于原来的证书过期了,续期之后下了新证书添加到keychain,这样就有两个同名证书了。
打开keychain,选择system,并看不到过期的证书,从菜单中选择View->Show Expired Certificates,就可以看到了,删掉完事。
编译程序时遇到了这个错误,点击详细信息,原来是ambiguous,xcode在keychain找到了多个证书,一个在system中,一个在默认的login中。Google了一下,有不少开发者都遇到这个问题了,对于我来说,其实是由于原来的证书过期了,续期之后下了新证书添加到keychain,这样就有两个同名证书了。
打开keychain,选择system,并看不到过期的证书,从菜单中选择View->Show Expired Certificates,就可以看到了,删掉完事。
不久前,Apple发布了新的开发者协议,不再限制app的开发工具(https://developer.apple.com/appstore/guidelines.html),这意味着开发人员可以使用任何工具来开发app了!
没错,Flash可以开发iPhone App。这无疑是个是个大消息,无数的flash开发者,瞬间变成了app开发者。我们在也不需要学习复杂的ObjectiveC,我们只要会简单的flash as,甚至会用flash做动画,就可以发布app了!
Flash做app,真的这么容易吗,我们来看一下。
能做app的Flash版本是Flash cs5
打开Flash cs5,新建,会看到一个iPhone OS选项:
选择这个选项,会创建一个符合iphone屏幕大小的工程。
接下来就可以开始做flash啦,做完之后再回来看。
flash做完之后,选择File>iPhone OS Settings,会看到这个对话框:
这里可以配置一些选项:
然后看一下Deployment选项卡:
这里需要配置app需要的信息,最上面的p12文件是证书和私钥,需要在申请apple开发帐号的时候制作并导出,注意导出的时候一定要加密码,并把密码填写在下面,否则无法发布。
下面就是provisioning 文件,也是从apple开发帐号后台制作得到的。
可以看出,虽然开发工具变成了flash,对apple开发帐号的依赖还是没有变化,依然要交钱,依然要各种麻烦的证书和文件。
下面填上app id,然后选择一个与provisioning文件对应的发布方式就可以了。
后面还有一个Icon选项卡,可以配置app的图标,很简单,不再解释。
点击Publish(发布),这个过程比较慢,根据不同的发布方式,要好几分钟,耐心等待。
发布成功后没有什么提示,设置里的Output file已经生成了,这样,一个app就制作完成了!
FallHunter 做了一个简单的动画,装到机器上一看,运行起来明显比较慢,修改为GPU硬件加速后,没有明显的改观。也许是由于我的机器(iPone 3G)比较老的缘故。
总结一下,用flash做app,看来是可行的,并且更简单,但也有一些潜在的问题:
flash的官方文档给出了一些优化建议,但似乎并没有太多可做的。
或许,flash做app,并不想我们想的那样容易;也或许apple正是充分了解到这一点,才把标准开放。不管怎样,开放都是一件好事,更多的选择都是一件好事,这一定会带来更多更好的产品,也会带来更多竞争,最终推动整个行业发展。
这几天开发中遇到一个怪事,一个按钮(超链接)不知道怎么回事就不能用了,跟了代码,发现超链接中的参数没有传到server上来,百思不得其解,想尽了各种方法,都没解决。你说你感到万分沮丧,甚至开始怀疑server。
后来用抓包工具查看了浏览器发出的请求,发现发出请求时就没有了连接中的get参数,看来还是浏览器的问题,尝试不同浏览器,chrome和safari都不行,firefox居然没问题。为什么不尝试ie?我才不在乎ie行不行呢!
再仔细深入重现问题的操作序列,发现了其中有一个重定向!忽然想起了当年peter同学在技术交流上介绍301和302的区别,这真如一道黎明的曙光闪现!没错,w3c标准,301为永久重定向,应该被缓存。查看代码,Django的redict函数,默认发出的是301!这样,看似“见鬼”的问题解决了。其实是因为重定向到了不带参数的url,使得问题看起来好像是参数丢失了,让我们误入歧途。
总结,重定向分为301永久重定向和302临时重定向,对于301来说,浏览器可以缓存重定向的结果,当下次请求未定向的连接时,改为直接请求重定向后的结果。这也是为什么在浏览器状态栏眼睁睁的看着一个连接,点进去却是另外一个。那我们的问题在firefox中没有发生?从这点上,看来firefox还不够“标准”哈。
在做iPhone开发过程中,收集了一些常见到问题,可以用作面试题目,供大家参考,如果这些问题对你来说完全没有难度,可以发一份简历到 join@mapiz.com
随着django程序越来越大,一个application里的model也越来越多,而django有个非常不好的约定就是所有的model都写在一个models.py 文件中, 而对于喜欢追求“优雅”的程序员来说,这的确很难忍受。
由python的特性,自然会想到将models.py 用一个目录代替,在__init__.py 中,import整个目录里的文件,这样python是认可了,django却不认! ./manager.py syncdb 的时候并不会发现目录下面的model。
搜了半天,发现解决方法比较简单,只要在每个model类中加上Meta的app_label 属性就可以了。
from django.db import models
class Test(models.Model):
class Meta:
app_label = 'myapp'
但还是觉得这个地方有点别扭,总是要记着加上这个,显得不那么自然。
这种做法是没有在Django官方文档里说明的,之前还用过另外一个Undocumented Technique,是在Django Single注册的时候,
models.signals.post_save.connect(flaggedentry_post_save, sender=FlaggedEntry, dispatch_uid=’mofin.store.models’)
其中 dispatch_uid 是一个undocumented 参数,指定这个参数后,则对应的single 处理函数不会被重复注册,出现这种问题的情况是,当上面的注册语句被直接写在文件里,而这个文件又被import了多次,则上面的语句会被多次执行,如果没有指定 dispatch_uid 的话,处理函数就会被多次注册,而Single发生时就被执行多次了。
参考资料
/*
做IPhone相关的开发也有一阵子了,过程中使用了不少来自互联网的各种工具与资源,在这里整理一下,希望能将互联网给我们的帮助再回馈给互联网,感谢互联网,当然,要先感谢祖国
*/
IPhone 的 App 固然有很多吸引人的地方,然而Web毕竟是大势所趋,已经有越来越多应用用 WebApp 的方式来实现了。所谓 WebApp,说白了就是Web应用而已,只不过是专门对手机尤其是IPhone的特点来定制界面,更有甚者,把界面做的跟本地IPhone App一摸一样,以至于我们都难以区分它是一个App还是一个Web。
先来看看各种漂亮的WebApp,除了用IPhone上的safari里面的默认书签,进到IPhone 的 WebApp 列表 http://www.apple.com/webapps/, 还有不少地方能看到WebApp的展示,如http://cssiphone.com/ 汇集了各种优秀的IPhone站点,这些优秀的CSS设计可以给你不少灵感
今天在server上配置ssh的key认证方式,这样就不用每次都输入密码。由于已经在其他机器上配置过,我直接把配置好的机器上的authorized_keys 里面的 publickey 考过来,新建一个authorized_keys文件,放在新的server的的.ssh目录中。
ssh一下,不行! 经过反复比较,都没发现问题,郁闷了很久。很久之后,突然发现是文件权限造成的:
自己创建的authorized_keys文件权限为 -rw-rw–r—, 修改成 -rw——- 就可以了。
看来还是算不上一个熟练的linux用户,linux与windows一个显著的区别就在文件权限上,也曾经因为文件权限造成过很多的问题和困扰,然而还是不能在第一时间内考虑的文件权限,是windows造成的习惯吧。看来轻松使用linux,一定要把考虑文件权限变成一种习惯。
今年冬天特别冷,以至于不少站长都选择迁徙到温暖的米国…
这里就来简单说说米国的主机,相比国内普遍的windows主机,这里更流行linux主机,目前主要有三种类型,按价格从低到高,有
是在一台物理机器上放置多个用户,每个用户在一个目录中,大家共享同一个硬件资源。这种服务一般会提供ftp、ssh,database等基础服务,还有控制面板,操作比较简单,适合初学者和个人站点。
推荐服务商: webfaction
是在一个物理机器上安装多个虚拟机,每个用户使用自己的虚拟机,一般配有web界面来安装系统,重启系统,设置密码等。这可能是国内比较少有的方式,这种方式介于sharedhost与dedicatedserver之间,以较为低廉的价格提供相对专业的服务。由于服务器是虚拟机,因此用户会拥有对此机器的全部权限,可以制定操作系统等,任意配置软件,但这对操作者要求也较高。VPS适用于绝大多数小型站点,一般vps服务商都提供多种性能的服务选择,可以随时根据需要进行扩展。
slicehost 与 linode 是如此流行又如此相似,因此,有不人专门来对比它们
http://journal.dedasys.com/2008/11/24/slicehost-vs-linode
http://www.kavoir.com/2009/09/moving-from-slicehost-to-linode-an-initial-vps-hosting-review.html
这里还有人做了比较专业的 benchmarks 对比
http://forum.slicehost.com/comments.php?DiscussionID=1951
这个从更专业的角度对比了更多的主机,其中包括slicehost 与linode
http://journal.uggedal.com/vps-performance-comparison
就是一个真实的物理机器,类似于完全托管,价格一般在几百美元一个月。这是专业的主机服务,用户拥有对整个机器软硬件的权限,但操作也更加复杂,重启、安装系统等工作要联系idc的人员来进行。适用于有专业人士维护的大中型站点。
主机选择是一个普遍的需求,以至于有很多站点专门来做主机服务商的评选,可以参考:
http://www.besthostratings.com/
等,如果是django站点,还有
http://djangofriendly.com/ 在 几个django相关的网站 中提到过。
执行 ./manage.py syncdb 的时候,django会查找新的model来创建数据库表,但当我们更新model的结构时(如增加字段),则需要手工修改对应数据表的结构。Django-evolution 正为解决这个问题而存在。
地址 http://code.google.com/p/django-evolution/
ratings是web2.0的基础元素之一,django自然不能缺少,个人估计它有望成为官方app
http://github.com/dcramer/django-ratings
tagging 是web2.0的另一个基础元素,这个库相当好用和强大。
http://code.google.com/p/django-tagging/
哈哈,还是web2的元素啦,这个是用户与用户之间的message系统,与django内置的message不是一回事,这个库比较简单。
http://code.google.com/p/django-messaging/
强大的图片处理、管理功能
地址 http://code.google.com/p/django-photologue/
一个基于django的CMS系统
你认为django的admin界面不够好看吗,看这个, 里面有漂亮的截图,相信你会喜欢。当然这个库也不仅仅是为了好看,它还有很多更方便的功能。
地址 http://code.google.com/p/django-grappelli/
这个库的作者就是上面的 django-grappelli 的作者,怎么样,别以为他只会做界面,看看这个,这是一个相当强大的文件管理系统,直接在admin里面就可以完成静态文件的上传和编辑。你还在用自己做的编辑系统吗,咳咳。
地址 http://code.google.com/p/django-filebrowser/
solr是做中小型搜索的首选,可以说是易用与强大的完美统一,django当然不会放过。solr不是已经很简单了吗,是的,但为什么要拒绝更简单呢?这就是django的哲学,我不骗你,编码真的可以是一种享受… 当然啦,还是有点缺憾,solr内存使用有些大呀…,但这不要怪到django头上。
地址 http://code.google.com/p/django-solr-search/
这跟电影《阿凡达》可没有什么关系,如果你熟悉web开发,早就应该知道 avatar 的意思是指web上用户的头像。这个应用就帮助你的django站点方便的增加用户头像的功能。
© 2009 FALLHUNTER. All Rights Reserved.
This blog is powered by Wordpress and Magatheme by Bryan Helmig.