自定义博客皮肤VIP专享

*博客头图：

点击选择上传的图片

格式为PNG、JPG，宽度*高度大于1920*100像素，不超过2MB，主视觉建议放在右侧，请参照线上博客头图

请上传大于1920*100像素的图片！

博客底图：

点击选择上传的图片

图片格式为PNG、JPG，不超过1MB，可上下左右平铺至整个背景

栏目图：

点击选择上传的图片

图片格式为PNG、JPG，图片宽度*高度为300*38像素，不超过0.5MB

主标题颜色：

RGB颜色，例如：#AFAFAF

Hover：

RGB颜色，例如：#AFAFAF

副标题颜色：

RGB颜色，例如：#AFAFAF

预览取消提交

自定义博客皮肤

-+

上一步保存

IT进行时的专栏

技术的使命在于创造价值

11月 06月 02月 01月

CameraLauncher插件：PhoneGap Android下导入大图片出现OutOfMemory的解决方案

PhoneGap是很棒的一个跨平台移动开发解决方案。该方案提供了一系列主流平台的底层封装，使得我们可以使用简单的HTML5 + javascript开展跨平台的移动应用开发，从而重用了我们传统应用开发的技能。目前该团队已经被Adobe收购，并贡献给了Apache，重新命名为Apache Callback（这烂名字怎么来的，怎么就让人感觉不到其价值呢）。目前还在孵化器。 Apache链接...

2011-11-08 16:04:01 143

GPS在Android的使用经验

GPS的开发、使用，有两个关键点：1. 选择并激活合适的Provider；2. 建立合理刷新机制。下面是通用的方法，以“选择并激活合适的Provider”： protected void getAndTraceLocation(){ //geocoder = new Geocoder(this, Locale.getDefault());; geocoder ...

2011-11-03 10:56:05 107

Android Asynchronous HTTPClient的实现和优化

大家知道Android对UI线程的反应时间要求很高，超过5秒钟直接ANR掉，根本不给你机会多等。而Android应用与后端系统的交互是最基本的需求之一，如何实现高效的Asynchronous HTTPClient，确保UI线程在启动任务后交由后端异步处理与服务器端的通信，尤为关键。Google过几个方案，要么太复杂要么不符合要求，基本都淘汰了，最后发现这一版本的实现不错，就拿来用了...

2011-11-02 17:16:13 125

20种工作流模式（Workflow Patterns）——大牛Aalst的作品

包括如下模式的详细介绍 Basic Control Patterns Sequence Parallel Split Synchronization Exclusive Choice Simple Merge ADVANCED BRANCHING AND SYNCHRONIZATION PATTERNS Multiple Choice Synchronizing Merge Multi-merge Discriminator N-out-of-M-join STRUCTURAL PATTERNS Arbitrary Cycles[自由循环] Implicit Termination PATTERNS INVOLVING MULTIPLE INSTANCES MI without synchronization MI with a priori known design time knowledge MI with a priori known runtime knowledge MI with no a priori runtime knowledge STATE-BASED PATTERNS Deferred Choice Interleaved Parallel Routing Milestone CANCELLATION PATTERNS Cancel Activity Cancel Case

2009-08-12

现有Working Copy如何与SVN库关联起来？

2010-01-23

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

itstarting CSDN认证博客专家 CSDN认证企业博客

码龄23年

IP 属地：新加坡

IP属地以运营商信息为准，境内显示到省（区、市），境外显示到国家（地区）

18: 原创

46万+: 周排名

202万+: 总排名

3万+: 访问

: 等级

439: 积分

2: 粉丝

2: 获赞

7: 评论

1: 收藏

私信

关注

热门文章

分类专栏

最新评论

工作流引擎是否应该建立在有限状态机（Finite State Machine, FSM）引擎之上？
shuishouhcd: 让我开眼界了，之前弄工作流就知道 jbpm,activities 也知道二者的流程设计语言 bpmn。这个wfmc还是第一次听说。不清楚 jbpm,activities 是否满足 wfmc 规范。我也认为fsm能够用来做wfmc的事情，尤其是复杂多变的审批流程操作。
Apache Cassandra Learning Step by Step (5): 实战性的JTwissandra项目
itstarting: 引用「第一个问题，我暂时采用了方案一，土办法。因为对于方案二而言：1. Super CF根本解决不了问题；...」 POST UPDATE: 其作者Patricio Echague建议使用MicrosecondsSyncClock，而非MicrosecondsClockResolution。其原理也很简单：如果一个毫秒内大于一次以上调用，第二次开始，每次调用在long类型的timestamp上加1 参考讨论：https://groups.google.com/forum/?fromgroups#!topic/hector-users/IfABWOh0HLg 所以最后的代码是： [code=java] /** * REF: * 1. FAQ * http://wiki.apache.org/cassandra/FAQ#working_with_timeuuid_in_java * 2. DISCUSSION: * https://groups.google.com/forum/?fromgroups#!topic/hector-users/IfABWOh0HLg * * @return UUID */ public UUID getUUID(){ ClockResolution clock = new MicrosecondsSyncClockResolution(); return TimeUUIDUtils.getTimeUUID(clock); } [/code]
Apache Cassandra Learning Step by Step (5): 实战性的JTwissandra项目
itstarting: 第一个问题，我暂时采用了方案一，土办法。因为对于方案二而言：1. Super CF根本解决不了问题；2. Super CF是一种有争议的概念，很可能会被废掉下面是第二个问题：我发现uuid会重复，导致循环调用addTweet后的实际tweet数量，少于预期的数量(e.g. 100次循环，预期产生100个tweet，而实际上只有不到90个）。为什么？因为如果是相同的tweet_uuid的话，就算用mutator.addInsertion，一样会replace掉（好比RDBMS的update）这块涉及的问题代码是： [code=java] /** * REF: http://wiki.apache.org/cassandra/FAQ#working_with_timeuuid_in_java * * @return UUID */ public UUID getUUID(){ //TODO: which UUID should we use to make sure it's unique? ClockResolution clock = new MicrosecondsClockResolution(); return TimeUUIDUtils.getTimeUUID(clock); //return TimeUUIDUtils.getUniqueTimeUUIDinMillis(); } [/code] 从我引用的讨论和作者Patricio Echague的说法来看，如果一个毫秒内可能产生多次调用的话，建议用TimeUUIDUtils.getTimeUUID(clock)。然而结果不是这样的，为什么？待解，打算直接跟作者沟通一下，可能是用法不当
Apache Cassandra Learning Step by Step (5): 实战性的JTwissandra项目
itstarting: 第一个问题发现在getTweets里： [code=java] public List<Tweet> getTweets(List<String> tweet_uuids){ MultigetSliceQuery<String, String, String> multigetSlicesQuery = HFactory.createMultigetSliceQuery(KEYSPACE, SERIALIZER_STRING, SERIALIZER_STRING, SERIALIZER_STRING); multigetSlicesQuery.setColumnFamily(CF_TWEET); multigetSlicesQuery.setColumnNames("user_uuid","tweet_content"); multigetSlicesQuery.setKeys(tweet_uuids); QueryResult<Rows<String, String, String>> results = multigetSlicesQuery.execute(); return convertRowsToTweets(results.get()); } [/code] 该问题是：如果通过MultigetSliceQuery.setKeys(Iterable<String> keys)传入系列key以进行批量的slice query，其结果并不依赖于keys的顺序，而是依赖于所在CF的建模。也就是说，通过CF_TIMELINE找到了漂亮的排序良好的tweet uuid，如果要获得同样排序良好的tweet列表，必须： 1. 一个一个的找，比如使用ColumnQuery，然后add到结果列表去； 2. CF_TWEET也要考虑通过timestamp来进行Column的排序——跟CF_TIMELINE一样方案一的做法感觉不怎么可取：这意味着需要跟Cassandra交互次数，瞬间X10倍方案二需要考虑一下，从感觉上来看，Super CF再说难免——这个需要进一步验证一下
Jetspeed2 Security
Swestheiyun: 相当不错的帖子，收获很大，谢谢

最新文章

提示

确定要删除当前文章？

取消删除