 |
|
|
| |
|
弊社ブログは２０１０年４月２６日からURLを変更いたしました。
ブックマークやRSSで登録されている方は、下記URLへ変更願います。 http://www.conit.co.jp/blog/ 今後とも宜しくお願い申し上げます。 ２０１０年４月２６日 株式会社コニット |
|
|
2010,04,09, Friday
Hey everyone, David here.
For those of you like me, who happen to be non-native Japanese speakers in a Japanese environment, here are a few tools that I use to help me get through my work day easier. Take what you will. Google: My Japanese is quite a handicap for me at the office, and any opportunity to inject English into my everyday tasks dramatically increases my productivity. This may sound simple, but I set my homepage to http://www.google.com/webhp. This insures that I can search all-English pages, just like anyone in the US. IME If you're a Mac user in Japan, you probably realized that the default IME is, well, "baka". Fortunately, Google has an awesome IME that knows your mind and the exact kanji you mean to type. http://www.google.com/intl/ja/ime/index-mac.html It also remembers long expressions, so after typing "o" in an email, you can hit space, enter to type "お世話になっています。" BAM! Jim Breen's WWWJDIC http://www.aa.tufs.ac.jp/~jwb/cgi-bin/wwwjdic.cgi?9T The EDICT dictionary is a life-saver. When I don't have the willpower to understand a lengthy email, a simply copy/paste into the translate words can get the main points of the mail across in no-time. |
 |
|
2010,03,31, Wednesday
Hi everyone, David here.
I'll be the first to admit that I'm no Flash expert. This is a trick which was taught to me just the other day, a trick so simple I felt stupid for not knowing it! Anyway, if you want to import AI images into Flash, here's the best way to do it. I did it on a Mac, but it should work for a PC as well. Step 1: Drag and drop the AI file onto the stage. This will work even if you don't have AI installed. Step 2: A window will appear, asking which AI layers you'd like to import. Pick the layers you'd like to import and click "OK". Step 3: The image will be imported in it's native AI state. Left as-is, this will eat up the performance of your Flash. To avoid this, select everything imported from Flash, right-click, and choose "break apart". Repeat this process a few times until everything is "broken apart".  That's it! You now have an image originally created in AI in native Flash. |
| |
|
2010,03,16, Tuesday
Mixi Mobile and Google App Engine: Some Lessons Learned
Hi everyone, David here again. I've been living and breathing Mixi Mobile and Google App Engine for over a month now. I have 1 Mixi Mobile game under my belt (well, 2 if you count 動物落下中), and I thought I'd share some key learnings. I tend to be the kind of guy that jumps into things head first, without really appreciating the consequences, and often without thinking beyond the next 2-3 steps. (Maybe that's why I can't get any better at "go", the Chinese strategy game). This has caused me and the team here some undue pain. If you are developing a game for Mixi Mobile on Google App Engine, hopefully you will have the foresight and wisdom to avoid the problems I encountered. If not, perhaps these notes will help. Lesson #1: Expect lots of users This ain't Facebook, and this ain't the App Store. Due to the (as of yet) small pool of Mixi Mobile developers, individual apps generate a lot more traffic than, say, your run-of-the-mill Facebook app. By virtue of just appearing in the "New Apps" section of the mobile site, you will get a tremendous amount of traffic. That makes Mixi Mobile an exciting place to be, but you need to take traffic issues seriously. Take a look at the number of users of apps that have appeared in the new app listing for 1, 2, and 3 days to get a feel for the traffic you can expect. Lesson #2: Prepare for the worst Being a naive, newbie Google App Engine user, I didn't anticipate some of the strange issues that come with GAE. Even if you pay to increase limits on CPU usage and datastore space, you app still has limits. In particular, be careful to know the number of simultaneous requests that your app can handle before Google disables it. That's right: Google disables your app if it's performance is too poor. Google says a typical app can have up to 500 simultaneous requests per second, but that assumes an average page request takes just 75 API. Unless you're some superstar engineer, your app will probably have poorer performance than that. If you're like me, your app will have MUCH poorer performance than that. So here is a checklist of things to do before release. -Prepare a "maintenance" version of your app, in case things go bad. The maintenance version shouldn't have any datastore or memcache reads, just a static page (or a fun little flash game like ours :) As you should know, Mixi Mobile will put your app in "JOIN停止" mode if it discovers your app is returning bad pages to its users. That means your app won't be listed in the "New Apps" section: a death sentence for up-and-coming apps. -Given your app's average CPU performance, figure out the max simultaneous requests per second. Should your app start to go over that limit, be prepared to switch it to the "maintenance" version. (thus avoiding the JOIN停止) -Take the time to tune your app's performance! This isn't just something that good engineers do. With other platforms, apps may start to get slow with poor CPU usage, but with GAE your app will be disabled! Read up on Google's site for how to optimize your datastore. Minimize the puts to your datastore and use memcache wherever possible. -Throw exceptions wherever possible. Again, having an "error found" page is way better than returning a server error directly to the user (and avoids the risk of the mixi mafia closing down your app). Trust me, thousands of users will find all kinds of problems with your app that no amount of testing will prepare you for. Lesson #3: Knowledge is power Google App Engine is a great tool for communicating the state of your app. When your app throws exceptions, show a detailed log. Make use of appstats to monitor page performance. And keep a running counter of new/active users, and anything else that may provide details about how your users are engaging your app. Lesson #4: First impressions are everything You may be debating when to release your app. It's the speed vs. functionality quandary that haunts all of us engineers. I take the position that speed is life, and I prefer to take risks over waiting yet another week for a release. That being said, because new Mixi Mobile apps appear on the "New Apps" list for a limited time, it is critical that your app succeed in that short time. Be ready. Prepare a community site for users to post questions and suggest ways to improve. Be sure you are making use of the Mixi social API to pump up the virality. Understand what makes successful social games, and make sure your app is following the same equations. Implement the game plan for how you will generate revenue as soon as possible. And at the very least, make sure your app doesn't crash in it's opening days. Lesson #5: One step at a time When I read blogs like this, and hear advice from others, and listen to feedback from my users, and listen to what "needs to be done" from the powers-that-be, I often end up feeling overwhelmed and hopeless. If I can pitch in my 2 cents: one step at a time. As you are ultimately the one developing the app, you have the final say as to what gets implemented. There is going to be way too much work for you to handle, so just stick to the priorities. And when you consider priorities, remember that the boring, backend stuff is often times more important than adding some new feature or improving the UI. Because what good is an app if it can't even open?
| http://www.conit.co.jp/labs/index.php?e=315 |
| Google App Engine | 03:41 PM | comments (0) | trackback (0) | |
| |
|
2010,02,18, Thursday
Hi everyone, David here.
As development continues on my Mixi game, I've been liking Google App Engine more and more. Before starting, one complaint I heard was that it is hard to adjust to the Google App Engine "datastore". Unlike SQL, the datastore is a "schemaless" framework, which stores instances of classes instead of rows in a table. You can run queries, but the queries are a bit limited. For example, you can't have more than one "greater than/less than" sign in your query. You also can't sort on fields that aren't specified in the WHERE clause of your query. It was a bit strange adjusting for me to, but I'm really starting to like it now. GAE has a very robust logging system that lets you track CPU time. Since you are mostly charged for CPU time, and pages with high CPU can actually become blocked, it is vital to tweak your queries to maximize efficiency. In typical SQL environments, performance always took a back seat to just getting the code to work. Now, I really have to be diligent about how I structure my data, how information is queried, and how it is managed. I like being in control of the cost of my app, and the adventure in finding inefficiencies in my code. Another concern with the datastore is that the data are hard to export, backup, and restore. I couldn't disagree more. With the remote api, you can do all kinds of things with your data, including exporting it to Excel, migrating it to a development server, and updating/restoring entire datastores. Here's all the info you need. http://code.google.com/appengine/articles/remote_api.html As I continue to hack away, I'll keep posting to this blog on any other learnings. Until then, happy coding. -David
| http://www.conit.co.jp/labs/index.php?e=301 |
| Python | 12:30 AM | comments (0) | trackback (0) | |
| |
|
2010,02,02, Tuesday
Being a newbie at web development for mobile in Japan, I was really surprised at how difficult it can be to make a simple web page render correctly for all Japanese mobile phones. Here are a couple of learnings.
Character encoding by carrier Japanese developers are all too familiar with the pains of encoding, but this problem is especially true in the Japanese mobile realm. Just like IE is different from other browsers in the PC world, mobile devices have differences in how html can be encoded. To know the carrier type, you need to inspect the HTTP_USER_AGENT header. The best way to do this is by using middleware, such as uamobile (http://pypi.python.org/pypi/uamobile/0.2.8). For now, I wrote a very simple Python function that seems to be working thus far: def get_encoding(user_agent): #since different keitai browsers have different encoding, need to account in header if "KDDI" in user_agent: #AU needs SHIFT_JIS encoding return 'SHIFT_JIS' else: #EVERYTHING ELSE IS UTF-8 return 'UTF-8' This function is very crude, and I'm still not convinced it actually works, so if you have a better way to do it let me know. As the function above shows, AU phones require SHIFT_JIS encoding, while all other carriers support UTF_8. This can be very annoying. If you use templates in your app, the template files must also be encoded in the correct format, which means the same template file cannot be used for both AU and non-AU phones. Rather than managing 2 sets of html files, I decided to pull in the contents of the file first, then encode the string appropriately. For example, here's how I use the function above to load the welcome page of my app: template_values = dict({ 'spam': 'eggs', }) path = os.path.join(os.path.dirname(__file__), (get_template_folder(os.environ.get("HTTP_USER_AGENT", "N/A")) + 'welcome.html')) self.response.headers['Content-Type'] = get_page_header(os.environ.get("HTTP_USER_AGENT", "N/A")) self.response.out.write(unicode(template.render(path, template_values), "utf-8").encode(get_encoding(os.environ.get("HTTP_USER_AGENT", "N/A")))) This takes the html template from the path, saves it as a string, then encodes the string to either UTF_8 or SHIFT_JIS. Image Types Another surprise was that DOCOMO phones don't support PNG images, which meant that I had to convert all my pngs to gif. Here's a useful page documenting support by carrier: http://ubiquitous.s17.xrea.com/shiyou.html Sessions and Flash You can't embed the Flash in a page if you want the user to interact with it, which means no passing variables into your Flash. Instead, you have to use loadVariables() inside your Flash to call a function that will return a query string of data. Typically, this is done using a session variable. Before opening the Flash, store the session ID and associate it with the variables you'd like. Then, after calling the Flash swf, pull in the variables by getting the session ID. Simple, right? Only problem is, most mobile phones don't support cookies, which is how most session handlers work. It took me the better part of a day to learn that hard truth. My quest for a good, mobile-friendly session handler continues. Some other hard-learned lessons -Make sure you test your app on as many mobile devices as possible before releasing it. Even with the same carrier, a web page can look very different depending on the device. -Even if it kills you to develop in Actionscript 1.0, Flash 1.1 is the only way to go if you want to make sure that your Flash will work on all devices. -When developing in Flash, test the app in a real device as frequently as possible. The Flash simulator just doesn't portray the dismal reality of a 3-year-old keitai. -Keep detailed logs throughout your app. Google App Engine's log viewer is a great way to catch provider-specific problems that you may have missed. -Take bathroom breaks frequently, and try to go outside at least once a day. -David |
| |
|
2010,01,20, Wednesday
Hi everyone, it's David.
For some inexplicable reason, my Japanese colleagues here at Conit, have let me, the gaijin, take the helm for one of their upcoming Mixi mobile apps. Yatta! Hey all you high school kids on your keitais, cuz here comes the American Ninja!  I'm new to Mixi, so I had to start with a little research. I was actually surprised that there is some English documentation available at the Mixi Developer Center. http://developer.mixi.co.jp/appli?lang=en However, as you can see, the English translation is only half done, and there's a lot in the documentation that isn't clear, even in the Japanese version. I'll be sure to put some more detailed specs out there in the coming weeks, but for now a couple of key learnings, in English for those of you (like me) who don't always have the enthusiasm to read Japanese. -Anyone can register as a developer for creating a Mixi app for PC. You just need a Japanese keitai. The process after registering is pretty straightforward; just follow the instructions on the Mixi developer center. -Creating a Mixi app for mobile is a little trickier. This requires a special "partner" account, and it's only available for legit companies (i.e. not for indie developers). You will need to log in to Mixi with this account to create and edit your application settings. Mixi will also allow you to have "test" accounts, so others can access your app while it is still in development. -There is not very much documentation publicly available for Mixi mobile app development. However, after getting a partner account, you will have access to all kinds of useful how-tos, including using the RESTful API, integrating Flash Lite, and all kinds of other fun things, along with sample code. Only problem is, it looks like none of this "exclusive" documentation is available in English yet. -Mixi mobile apps must adhere to a stricter set of standards than PC apps. Mixi recommends using Google App Engine for development (yet another service I am learning now) Stay tuned for more details. I think I'm turning Japanese. |
| |
|
2009,12,25, Friday
At long last, my childhood dream has been fulfilled: I got to help make a Japanese video game. Sure, even if my part was simply to do some English translations, it's still cool!
 Like Mortal Kombat meets Hello Kitty, you play badminton against your enemies to make your way to the end. The game takes place at the ends of your imagination: somewhere in a Chinese forest. It has everything that you'd expect from a Japanese video game. Cute, dancing animals. 3d graphics. And even a YouTube video that is more Japanesey than the latest Utada Hikaru album or bucket of KFC on Christmas. And in true Japanese comical quirkiness, you control your animal's play not with your fingers, but by blowing into your iPhone's microphone. Of course, it's for iPhone/iPod touch. And completely free to download. I know I'm a little bias, but when it's free, why not give it a try?
| http://www.conit.co.jp/labs/index.php?e=268 |
| iPhone | 07:56 PM | comments (0) | trackback (0) | |
| |
|
2009,12,01, Tuesday
Hello, it's David again.
For my latest project, I've been given the task of building a simple, web-based image editor. This editor will pull images from flickr, allow the user to edit them, then save the edited images in a zip file. For the server-side, we're pretty much stuck with PHP. However, we have some freedom on the client-side. I went back and forth on the right technology for this task. I'm pretty comfortable with Flash and Flex, and assumed this might be a good task for Flash. However, I also decided to check out jQuery, the powerful Javascript-based library that's been getting a lot of attention lately. And I'm really happy with my decision! A couple reasons why. -Unlike Flash, jQuery requires no plugins, no special SDK, and no "compiler". All you need is an HTML editor and a sense of adventure. -Everybody knows how to use Javascript. If this tool ever needs to get updated, it is much easier for me to pass it off to someone else. -There is plenty of documentation, examples, and tutorials for jQuery. I was able to build most of the functionality around a couple of simple tutorials I found on the Internet. One key resource was the jQuery UI. If you haven't used jQuery, I highly recommend checking it out! |
| |
|
2009,11,16, Monday
The latest assignment in my Software Engineering seminar class: find any journal article related to software engineering and make a PowerPoint presentation about it.
With all of the work that PhDs have been pumping out at Google (http://research.google.com/pubs/papers.html), I felt this assignment would be a good excuse for me to actually sit down and read some of it. What a better place to start than MapReduce (http://labs.google.com/papers/mapreduce.html)? My friend, perhaps the biggest advocate for functional programming, concurrency, and distributed programming methods, heralds MapReduce as one of the great works to come out of Google. Many everyday data mining tasks, like those done all the time at Google, can be conceptualized as a 2 step process. First, a 'MAP' function is applied to a series of keys and values. The result of the function being mapped is then fed to a 'REDUCE' function, which returns something with meaning to the user. Here's an example, quoted directly from the article: map(String key, String value): // key: document name // value: document contents for each word w in value: EmitIntermediate(w, "1"); reduce(String key, Iterator values): // key: a word // values: a list of counts int result = 0; for each v in values: result += ParseInt(v); Emit(AsString(result)); The map function emits each word plus an associated count of occurrences (just ‘1’ in this simple example). The reduce function sums together all counts emitted for a particular word. Count of URL Access Frequency: The map func- tion processes logs of web page requests and outputs ⟨URL, 1⟩. The reduce function adds together all values for the same URL and emits a ⟨URL, total count⟩ pair. Reverse Web-Link Graph: The map function outputs ⟨target, source⟩ pairs for each link to a target URL found in a page named source. The reduce function concatenates the list of all source URLs as- sociated with a given target URL and emits the pair: ⟨target, list(source)⟩ Term-Vector per Host: A term vector summarizes the most important words that occur in a document or a set Being a novice at distributed computing, and now almost 8 years since my undergrad computer science classes, I was really surprised at how simple the concept works. To do a 'MapReduce' in a distributed environment, Dean and Ghemawat suggest setting up a 'master' scheduler, several 'map' workers, and several more 'reduce' workers. The master keeps track of the status of each worker, to allow for rescheduling if a worker machine fails. The map workers are tasked with a subset of the initial data, and their job is to map it. When they are finished, the master is notified and assigns a reduce worker. The reduce worker reduces the data and append the result to whatever it had already reduced. The key is in an intermediate 'reduce function' that tells the map worker where to put its results (such as key MOD R, where R is the number of reduce workers). Based on its location, the reduce workers can effectively work on unique sections of data. The reduce workers then output their own output file as a result, allowing for several reduce workers to chow down on the data simultaneously. If your curious to learn more, I highly recommend giving the article a good read. Find it here. |
| |
|
2009,10,28, Wednesday
Hi, David here.
Being the guy in charge of taking an iPhone app and making it "social", I've spent hard earned blood and tears tinkering with the Facebook iPhone API, making crazy UI windows for Twitter, and managing a server to track user scores and information. It was a mess. I had to worry about making sure the Facebook connection, Twitter connection, and server connection were all working and in harmony with each other. I had to do things like write delegates for Facebook permissions, account for user activity if they are offline, and look at how to securely pass information between a device and the server. Then came Open Feint (http://www.openfeint.com/). If you're not familiar with Open Feint, it's a freely-available iPhone API plugin for your app. Import the library, add a couple includes, sign up your app at the Open Feint site, and you're pretty much good to go. Want to post a message to a user's Facebook page? Here's the code. [OFSocialNotificationService sendWithText:@"Here's a message for the user's wall"]; Oh, and it will send to Twitter too, so don't bother learning how to use the Twitter API. Did I mention you can send images too? And while you're at it, why not send a user's top score? [OFHighScoreService setHighScore:10 withDisplayText:@"10 points" forLeaderboard:leaderboardID onSuccess:OFDelegate() onFailure:OFDelegate()]; Bam. That's it! Plus, Open Feint can automatically prompt the user to post to Facebook/Twitter as well, so you're only using 1 line of code to perform several functions across multiple platforms. All of the ranking information is kept somewhere on the Open Feint side, and there's a spiffy (albeit a little sci-fi) UI for users to see their rank. There's also the ability to compare scores with friends, play other Open Feint apps, unlock achievements, etc, etc etc. If you want to try it out for yourself, get Pocket God for iPhone.
| http://www.conit.co.jp/labs/index.php?e=254 |
| iPhone | 08:16 PM | comments (0) | trackback (0) | |
| |
