-
Frequently Forgotten Fundamental Facts about Software Engineering
Great list of Software Fundamentals.
-
Clamato: A Smalltalk Dialect for JavaScript
Clamato is a Smalltalk dialect that is designed to operate within the JavaScript runtime. (For non-Canadians: “clamato” is what you get when you add clams to tomato juice. Some consider this an unholy mixture; others, a tasty treat.)
- Tags:
- smalltalk
- programming
- javascrit
-
DEFUN 2009: Multicore Programming in Haskell Now! « Control.Monad.Writer
Overview of concurrency and ghc for Haskell programming
-
Frédéric Wenzel has a great series of L10n blog posts going and there has been a lot of discussion of L20n work at Mozilla. I ping’d Fred to check in and share an idea with him… What if you could directly edit the copy on the staging server of a website and have it transparently save your changes in the background without messing with PO files, SVN access, etc You’d eliminate lots of problems that localizers have… and provide a richer, fun editing environment. Like any idea worth building… I found out it’s already been invented A few months back when I pitched this idea to Stas Malolepszy, he mentioned that Gandalf already thought of the idea and built a prototype. I’m realizing that this has been sitting in my TODO list for too long and I’m better off doing a brain dump in this blog post. Here’s my take on the idea: Design Constraints: Keep po files as the backing store Work as much as possible with existing gettext tools Use direct object manipulation for the UI - pick strings directly from page, see live updates Requirements: Let localizer view a web page and pick a string to translate Display an editor widget that sit on top of or beside the page Display the msgid and msgstr. In practice this is the English String and the Localized version. As they type, redisplay the page with their updated translation Provide a revert button Provide a save button. Save persists this string back to the po file server which commits the change to SVN. PO LiveEdit at 10,000 feet
PO Enhanced HTML – In PHP or other web code, instead of making calls to gettext methods, a set of wrapper methods would be used which add metadata to the HTML output. This would basically add the msgid to a span tag that surrounds the output of the msgstr. This would extra metadata wouldn’t affect the display, but would capture the semantics of a localized string. Old PHP code <p><?= _(‘Be the Difference’); ?></p> outputs <p>Fai la differenza</p> New PHP cde: <p><?= _w(‘Be the Difference’) ?></p> outputs <p><span id=‘md5_58cbc46092296cbe517d748685f52838’>Fai la differenza</span></p> PO Edit Client - This editor would use the msgid or some other token (such as the md5 hash of the msgid) from the enhanced html, to retrieve the information for an individual string and display it for editing. The comments, English translation, and Current localization string would be displayed. The editor would be aware of the current locale which is a page. It would be a live editor where changes would be reflected in the web page as you type. PO Edit Web Service – The server manages the collection of messages.po files for a web application. It’s provides read and write access to the PO Edit Client, one string at a time. It manages commits to SVN and conflict management. Technology: So three are three components to build… PHP gettext wrapper libraries, which are pretty trivial and produce the enhanced metadata in the HTML, a Server and a Client which lives within the browser. Server Either a stand-alone python server using Stas and Zbigniew’s [https://wiki.mozilla.org/Silme Silme library], or integrated into an existing web based L10n tool like [http://en.wikipedia.org/wiki/Pootle Pootle], it would provide a REST web service for editing po files by locale and msgid. Client The client can be built as either: Pure JavaScript included from the page Addon – Firefox/Fennec Extension Pure JS has the benefit of working with any browser (Safari on iPhone, IE 6 in corporate dungeon, etc). It has the negative affect of introducing L10n only code that you wouldn’t want to push to production. It adds another integration point to every app. The Addon has the benefit of being totally isolated from the specific web application’s codebase, which makes for easier adoption. The client would have the ability to use the PO Edit WS without any same-origin policy limitations. Downsides are that it’s requires Firefox or Fennec and it is an extra step for localizers. Either way, a simple textarea will be a good start for a prototype. Localizers will be loosing any features of their current text editor (say POEdit), but they will gain rich “preview”. For a prototype, the addon route could be built out of an existing extension, such as Jetpack Slidebar or Ubiquity pageLoad command, since it’s a more rapid development env. Considerations: The devil is in the details, here are some design decisions. By default, does this introduce a new requirement for a L10n preview environment? Or is the web application in a testable state? Adding String Metadata changes the web application and invalidates it for QA, unless you ship this metadata in the production version also. The ’right’ thing to do would be to introduce a localization step into the SDLC, but this might lower adoption. Or you could focus on making the implementation of the String Metadata really light weight, so it would have minimal overhead and not need an additional phase, since it could ship to production and other applications can invent new uses for this metadata. Exposing hard to reach state: Many strings are hidden behind a hard to reach sequence… such as error messages. A common practice in web app development is to expose every part of the app through testing hooks. Many large applications grow these features through time, such as allowing testers special query string parameters for each error condition to simulate the error. Another example is web apps with emails; provide urls so that each email is a click away w/o actually running through the registration process. These kinds of hooks would make translation easier and you’d have to list them somewhere so it’s easy to find them all. These become a requirement for a live web editor, unless you make the user jump through steps to reach all the states of the UI. Out of Scope(?) but on the Radar A real-time synchronization between the client and server would be ideal, so that multiple localizers could see who was editing a string and to reduce conflicts. Mike Morgan and Fred have suggested Bespin which is a freaking awesome idea. Wrapping up If we had a web based live editor for translating sites, this could be a huge win for localizers and the people of earth. Translating a website is one of the most painful and dangerous workflows I’ve seen. You know we have an amazing community, if they are willing to put up with the draconian toolchain we have today. Throwing everything out, is simply not an option, but if we can make a small evolutionary improvement towards a live preview edit workflow which hides revision control systems and text files… There are plenty of sticky corner cases and whiz bang features one can dream up, but I think building a prototype for this is a tractable problem. I did some brainstorming with Fred this morning and he had lots of other cool ideas and good observations on how this would work in practice.
- Tags:
- programming
- mozilla
- research
- webdev
-
Hidden Features of PHP? - Stack Overflow
A great list of 'hidden' PHP features.
- Tags:
- programming
- php
- features
- idioms
-
Nothing earth-shattering here… but I wanted to capture some ideas that the webdev team has discussed in terms of how we share our code between projects and with the community at large. Of course 100% of our code is open source, but we want to do a better job of letting others use and contribute to our libraries. Screenshot of a typical project layout A typical project Let’s talk about a theoretical new project foomo which is the code behind Foo.mozilla.org. This project may reuse a couple libraries as well as host it’s own code. Let’s assume this is a project has the layout pictured to the left: In bin we have various Python and shell scripts which are executed via cron or CLI. These scripts depend on the config directory for configuration and the lib for libraries of code. I won’t focus on the bin part of the project, but it could follow the pattern below, but using a Pythonic packaging idiom. Let’s assume that the web directory houses a Kohana PHP project. Under the web/application directory there are typical these project specific directories: config, controllers, helpers, hooks, libraries, models, andviews. In addition to application, Kohana also provides modules and system directories. Let say that foomo project reuses a Mozilla WebDev PHP library barlib library it will be located under modules. system is where Kohana stores it’s framework code that is overridden by modules and application code. But how do we manage foomo and barlib codebases? Version Control The authoritative code repositories for this website would be in atleast two places. If we keep all the code for foomo under one project, say svn.mozilla.org/project/foomo, this makes it easy to deploy and manage. The mainline of application specific code would be changed from here. The second codebase is for the library barlib. The mainline of development would happen on github.com/projects/barlib. Let’s look at the source code layout of foomo and barlib to see how they relate. foomo's module directory contains barlib barlib's project layout So foomo’s web/modules/barlib on the left is a subset of barlib’s development tree on the right. A read only copy of this dist directory, heck even just a tarball distribution of it, comes from github and lands in foomo’s web/modules/barlib. As we want to enhace barlib, we work in that codebase on the right. barlib is it’s own project, so development includes running it’s tests, etc and then creating a release version to be imported back into foomo, on the left, as needed. Keeping the official repository for reusable libraries separate introduces some disadvantages, but is worth it. Disadvantages:
More complexity and administrative overhead Requires more discipline You have to manage dependencies between libraries and apps Increases development costs
Advantages:
Encourages Reuse Removes barriers for community contribution Makes QAing and releasing components possible
All Growed Up As code in foomo solidifies or another project wants to use chunks outside of just foomo, the various pieces of code can be pulled out into a module and moved from web/application to web/modules/<library name>. We’ll have to re-QA foomo after this code extraction, but we will gain the benefit of reduced development on the second project and anyone who needs it won’t have to pick through foomo internals to copy and paste the tasty chunks. If the second project is a CakePHP project, then all it will need to do is write CakePHP wrappers analogous to the very this Kohana specific layer of barlib. Everything Cannot Be Reused Not ever line of code can be reused. A lot of web development is about crafting a very specific solution. Localization, error handling, and coding conventions introduce challenges. That said, we should spend the extra time it takes to publish and integrate dynamite WebDev libraries.
- Tags:
- programming
- mozilla
- webdev
-
pushing pixels with canvas at hacks.mozilla.org
Great post on updates to createImageData in Firefox 3.5.
-
Field: Experimental Programming IDE | Digital Tools
MIT Media Lab staff (the Open Ended Group) is working on a new kind of programming tool called Field. It connects everything. Not only various programming modules and components, but also different styles of generating, editing and testing code are provided. For example textual coding with auto-complete, visual coding, timelines, live-coding, flow-management etc.
-
It’s impossible to start working on a complex system no matter how well you understand it (or more likely, think you understand it). Evolution is the only way. And another characteristic of all evolution (biological evolution in particular) is this:
-
On Ruby: Diamondback Ruby Interview
Diamondback Ruby uses a combination of static and dynamic checks to ensure that Ruby programs are well typed. Programs that can be checked purely statically (which we hope will be most of the time) will have no overhead at all since the programs can be safely run by a traditional Ruby interpreter unchanged. However, if the program does require a runtime check, then individual objects or methods may be instrumented to ensure they don't violate their types. When dynamically checking objects, we instrument the eigenclass of the individual object so that only methods calls to that object must be checked (not every object of the same class).
-
Haskell Platform Download (Beta)
This is the beta release of the Haskell Platform, version 2009.2.0: a single, standard Haskell distribution for every system.
The Haskell Platform is a blessed library and tool suite for Haskell culled from Hackage, along with installers for a wide variety of systems. The contents of the platform are specified here: Haskell: Batteries Included.
-
PhoneGap | Cross platform mobile framework
PhoneGap is an open source development tool for building fast, easy mobile apps with JavaScript.
If you’re a web developer who wants to build mobile applications in HTML and JavaScript while still taking advantage of the core features in the iPhone, Android and Blackberry SDKs, PhoneGap is for you.
-
The Future of Mobile (Live from the Web 2.0 Expo) - ReadWriteWeb
The question that Grisby raised during his presentation is an important one: are native applications really the future of the mobile web? Applications built specifically for one device, such as the iPhone, aren't necessarily any more capable than those built using web technology. In fact, they can even tap into the functionality of the phone's hardware itself like the accelerometer and geolocation features. (Really!)
-
reCAPTCHA is a freely available CAPTCHA implementation. It distinguishes humans from computers. This may be useful for:
- Tags:
- programming
- api
- web
- security
- captcha
- webservice
Copyright © 2012 Me. All Rights Reserved. Running on Sweetcron v1.08e
This site is monitored by mon.itor.us