Feeds:
Posts
Comments

Archive for the ‘Web Development’ Category

My setup has been the same since quite a few years now: I have a Keepass file on Dropbox, and I use several different applications and apps on multiple devices to access and update that file. Which applications, you ask?

On my Macs as well as on my Xubuntu machines I will use Keeweb. Despite its name, it gives you a desktop application that natively accesses (and syncs) files on Dropbox. This is the application I go to for when I want or need to reorganise the Keepass file, e.g. to rearrange groups or import lots of account data.

I would use Keeweb on a Windows PC as well – if I had one. At work, we have no free choice of which application to use to store passwords, but luckily we do have the “official” Keepass Password Safe at our disposal.

On Android my favourite Keepass app is called Keepass2Android. I will admit that I made that choice a few years ago, and haven’t checked on its competitors recently (are there competitors of note, by the way?). But it does what I need it to do; it accepts Dropbox as cloud storage and it will even merge changes from the local version and the Dropbox version when it detects differences between the two during the synchronisation process. That last one is a killer feature, and it hasn’t failed me a single time in the years I have been using it.

On iOS the situation is a little more complicated – at least, that how it feels to me. I wrote earlier about KeePassium, and that is still my app of choice. I like the interface, and it does all I need when I look for account info (you can store more than just passwords there!).

But in order to sync my central file on Dropbox, on iOS the app has to go through the “Files” app from Apple. Files-the-app is capable of showing files of all kinds on the iOS device, as well as the files on several cloud file systems, like Dropbox. What is less clear to me, however, is how quickly “Files” notices changes on Dropbox and picks up the latest version of my central KeePass file. I also have had trouble getting the latest version of my file (as changed on Android, for example) onto my iPhone. Although I must admit that the last few weeks fared better: I haven’t noticed anymore missing syncs lately. What I can’t say is whether the issue was/is with Files rather than KeePassium or even my internet connection…

Anyway, when it comes to passwords I want to be sure that I’m not missing any information – or worse: I don’t want to overwrite my updated central file with an older version on iPhone! That’s why I currently always check the “last updated on” date of my Dropbox file in Files before opening the file again. Of course my Dropbox account is protected with a password, but I don’t think that is what Andrei Popleteev means when he’s writing about “How to sync KeePassium with Dropbox“.

Manually checking the file date on iOS is not an ideal situation, I know, but to me that check is a small price to pay for the greater good of having my account data available on all the platforms I use! And for me, KeePassium is still the way to go on iOS.

Read Full Post »

“Seeing” things as colors or sounds has always intrigued me, so I had to have a look at the “What Color Is Your Name?” website. Don’t expect an extensive and scientific explanation of the phenomenon; just enjoy the results. Here’s what the alphabet look s like for Bernadette:

I can see this site being used to select a color scheme by website designers!

Read Full Post »

Last week, I did loose a lot of time in what should have been a quick ColdFusion hack. My colleagues and I were just trying to set up a web service-based solution for a simple problem: they had a JavaScript page that needed a bit of data for which I already had the code in ColdFusion. So I created a new directory in an existing application, whipped up the required code in ‘index.cfm‘ to return a bit of JSON and tested the result from my browser… only to get an “Error 500 - Application index.cfm could not be found“.

Weird, heh? The required file was there, so why could CF11 not find it? Adding an ‘Application.cfm‘ did not help, neither did repackaging the code in a CFC. On CF8, on the other hand, everything worked as expected. So what was going on?

It took some time, but I did find the explanation: CF11 reserves the directory name ‘api’ for special treatment, so you can’t use it like any other directory name – and of course that was the name I had chosen! Adam Tuttle described the situation nicely in 2015:

Funny you should mention that the issue is inside an /api folder. I’m trying to track down the same problem, except I’m directly accessing an index.cfm (sort of — onRequest intercepts the request and redirects to CFCs as appropriate — it’s a Taffy API) and I’ve found that renaming the folder from /api to … literally anything else… works fine. It’s almost as if something in CF has special meaning at /api, like the special /rest mapping does.

Indeed, renaming my directory solved the problem – too bad it took me so long to find the cause. On to the next problem!

PS. Adam Tuttle has more to say on the subject, but his post on the subject has disappeared: the URL ‘http://fusiongrokker.com/post/coldfusion-11-sometimes-chokes-on-api‘ no longer points to the relevant text, but is redirected to another blog also belonging to Adam Tuttle. There, unfortunately, the post is NOT available. I won’t call this a case of linkrot, but it’s not good either. Luckily, the Wayback Machine has a copy of the page, including a few comments…

Read Full Post »

Brent Simmons isn’t a new name in this blog – I have cited his name several times since 2001. A few days ago he wrote:

It’s been years since I could build the Frontier kernel — but I finally got it building.

[…]
The high-level goal is to make that tool available again, because I think we need it.

The plan is to turn it into a modern Mac app, a 64-bit Cocoa app, and then add new features that make sense these days. (There are so many!) But that first step is a big one.

“Frontier Is Interesting”, says Jim Roepcke – click to see what he writes

It’s an interesting development, from several viewpoints. I wrote some of my first “web applications” in Frontier, and that makes that Frontier will always have a special place in my book of tools. It’s also nice to see a relevant piece of software evolve so that it continues to run on modern hardware and OS’s. At some point, I will certainly download and run a copy on my Mac.

But the question is: do I want to go back to developing stuff in Frontier? Do you want to?

Read Full Post »

More than 8 years ago, I wrote about the Google App Engine as a platform. Much as I liked the concept, I also remarked that it would be… great to have a complete development environment within the browser, coupled to a runtime.

Turns out that Fog Creek, the software company founded by Joel Spolsky, has built just that: “a developer playground for building full-stack web-apps fast“. It’s called Gomix – but it was called HyperDev during the development of the product. That ties in neatly with my reference to HyperCard as an example of a simple tool that allows anyone to built the tool she/he needs. Nice work, Joel !

So here it is, my first “app” in Gomix (just for fun and with lots of tongue in cheek):

gomix.png

Read Full Post »

I do find it important to refresh my memory from time to time, even when it comes to something that I do quite frequently, like writing code. A reminder about why some things have to be done in a particular manner, re-reading the exact details about how to do something, or just brushing up on a subject supposedly known only to find that things have changed a bit in last few years: all good reasons to never stop reading.

That’s one reason for me to read “The Basics of Web Application Security” on Martin Fowler’s site. It’s also a good intro to newcomers in the field – and to top it off, it features an xkcd cartoon! What more can you want?

Click the image to see the cartoon in all its glory


Click the image to see the cartoon in all its glory

I’m waiting for further additions to this text!

Read Full Post »

It seems the debate about in-browser editors is ongoing, in a good and serious way. Dave wrote about it again, in “There’s a content-editable community“. He points, amongst other things, to an Indiegogo project called ‘ProseMirror‘. I have only read the project description, not the code; it seems to me that it is part editing tool, part content representation. That makes it similar to Dave’s OPML Editor, and both will allow you to represent the content as you like, depending on the transformation you apply to the content. That’s a good approach, in my view, because it makes the tool very flexible.

prosemirror.png

Of course, ProseMirror could be the editing environment for a Wiki! Storing Wiki-content in a format that is not dependent on a representation such as HTML is the basis for re-use of that content in as many forms as you need/want. I hope Marijn Haverbeke reaches his goal, and then we’ll see if someone picks up ProseMirror as the basis for a Wiki, a blogging tool, etc. From what I remember of the JSPWiki implementation, it should be relatively easy to whip up a ProseMirror “storage provider”  for JSPWiki that does exactly that: use the ProseMirror content format as the corner stone of a Wiki. Any takers?

PS. If the Indiegogo project should disappear, then you’ll also find more details on prosemirror.net

Read Full Post »

Dave asks: should there be “Editing APIs for Wikis?“.

Wikis have been “invented”, to use that word, to make it possible for anyone to edit a Wiki page inside the browser. In a Wiki, content is more important than fancy layouts. Wiki editors thus prescribe a simple markup system for things like ‘bold’ and ‘italic’ lettering, bullet lists, etc. Creole, the attempt to unify dozens of markups, has never been a success. When going from one Wiki to another you may need to adapt your markup automatisms. These markup languages are rather similar, so in practice adaptation from one to another isn’t too hard.

Would it be nice to have a WYSIWYG editor in your Wiki? For some people, the answer is yes. They will indeed be more comfortable with an editor that resembles the editor they use for writing books or letters. But many Wikis allow you to change the editor used for editing Wiki pages. At work, I have activated the FCKEditor (aka. CKEditor) in JSPWiki, and currently our users can still choose the editing style they prefer.

All/most Wikis store the user’s content in their own markup format, not in HTML. The MyWord Editor that Dave Winer has built works differently, if I’m not mistaken: it is a WYSIWYG layer for HTML editing. It should not be too hard to convert the HTML from a simple HTML editor to whatever markup the Wiki uses. But even for a single editor that would require a convertor for multiple Wiki markup dialects.

Yet another Wiki editor: Eclipse and Textile

Yet another Wiki editor: Eclipse/Mylyn and Textile

In the end, the real question is: what would be the added value of such an API?

The purpose of a Wiki is to capture information and not layout. That is why the built-in editors are relatively simple. For hard-core Wiki authors, an HTML textbox plus knowledge of the local markup language will be enough. Occasional authors will have to make do with the built-in MOLWYSIWYG (More Or Less WYSIWYG) editor. I suspect most occasional wiki authors won’t be authoring texts in more than one Wikis, so they will deal with a single variant only.

Would a common API be a good idea? Of course! But such an API would already exist if it served a greater purpose beyond the technical promise of plug-and-play editors.

If you ask me, Wiki’s would be better served with a common markup language like Creole or Markdown or ReST, rather than an editor API. If you think otherwise, then just build such an API. I’ll be happy to write about it!

PS. For a comparison between Creole, Markdown and ReST, check out “Why Markdown Is Not My Favourite Language“…

Read Full Post »

I have been spending more than a hour trying to find out why a :hover selector on a <span> wasn’t working in Internet Explorer 8 – many documents on the Web are clearly stating that it works. In the end, it was the W3Schools.com website that came to the rescue, in the form of a note:

Note: In IE there must be declared a for the :hover selector to work on other elements than the element.

CSS Selectors explained at W3Schools.com

CSS Selectors explained at W3Schools.com

You had better make sure that the DOCTYPE is indeed declaration is indeed on the first line in your HTML… and then everything works smoothy, as far as I can tell. Whew.

PS. No, I will not try to explain why I still have to build code that has to work in IE8, and not in a somewhat more recent version…

Read Full Post »

Last night, I attended the CFUG Belgium meeting, entitled the “CF11 Launch Party” (CFUG Belgium is the belgian ColdFusion User Group). We had two speakers. Rakshith Naresh is the ColdFusion product manager at Adobe; he spoke to us from India about the new features of ColdFusion 11. Technically, the situation wasn’t perfect, but all in all it was good to see that Adobe, or at least Rakshith, cares about CF developers in a small country like Belgium, and his overview was worth listening to.

The second speaker of the meeting was Alwyn Wymeersch, who explained the basics of AngularJS. I liked his approach of the presentation, with lots of demoes, and his courage, trying to do it all with live coding. Good job!

Click the logo to go to the CFUG website.


Click the logo
to go to the CFUG website.
Be warned, though:
this site isn’t up to date!

I look forward to testing our current apps on the latest version of CF, even though I won’t be using many of the recent novelties. I would love to try and develop a mobile app with CF11, but our mobile app users are colleagues on the move, using iPads and Galaxy Tabs to access company resources. Their mobile devices are under control of a ‘Mobile Device Management‘ platform like MobileIron, AirWatch or XenMobile (sorry, I forgot that Gartner now calls this ‘Enterprise Mobility Management‘).

So I hope that Adobe will pay attention to the developers of large enterprises, whose mobile apps must also be able to run in an MDM container, with all that entails in terms of limitations on how to access certain functionalities of the devices. PhoneGap is supposed to be compatible with MobileIron AppConnect, but has it been tested when an app is built with CF Builder? And what about the other MDM’s? Are there gotchas in this scenario? How about that on-device debugging? Etc. There’s still work to be done, that’s for sure! What will CF12 bring, eh?

PS. To all those who registered for the meeting but weren’t there I say: it pays to attend! There were nice prizes to win in the closing raffle, and a third of the attendees went home with a nice software package (well, at least I hope I get my package delivered soon ;-)

Read Full Post »

We all turn to the Wikipedia from time to time, whenever we need a bit of authoritative info about a subject. You may not have noticed it, but the “look and feel” of Wikipedia essentially hasn’t changed in a decade. As an encyclopedia the Wikipedia focuses on its content, and the accessibility of that content in terms of search and navigation. “Content” is also the focus you’ll find in most Wiki software, and the basis of the Wikipedia is of course Wiki software called MediaWiki.

Ten years is a long time in the history of the web, and things have changed since the start of Wikipedia. Ten years ago, personal computers were the only way to access the web; today, an ever increasing number of users surfs the web on smartphones, tablets, PC’s and smart TV’s. Ten years ago, producing information for the Wikipedia was essential to get it up and running as an broad encyclopedia; these days, I’m guessing there are relatively much more consumers than writers of Wikipedia content. Ten years ago, there was only a web interface to interact with the Wikipedia; today there are apps on all kinds of platforms to access all or parts of its content in a specific form on all those different types of devices.

Thus it should not come as a surprise that someone decided to apply the user interface lessons of the last decade to the Wikipedia: meet WikiWand.

The Dutch entry for "Thee" ("Tea") in Google Chrome on a Mac

The Dutch entry for “Thee” (“Tea”) in Google Chrome on a Mac

There are two ways to use WikiWand: you can either access the Wikipedia through the WikiWand website (just use the search in the top right corner), or you can install the WikiWand browser plugin (for Chrome, Firefox or Safari) and set it up to be your default way of using the Wikipedia. I’m currently trying out the website, and I must admit: it looks good, on my Mac as well as on a smartphone. The smartphone version is perhaps a bit too visual, putting all the pictures before the text of the lemma. But the navigation menu on the left allows you to jump to wherever you want, so many pictures are only a problem if you access the web over a slow (and possibly expensive) network connection.

The Dutch entry for "Thee" ("Tea") in Google Chrome on an Android smartphone

The Dutch entry
for “Thee” (“Tea”)
in Google Chrome
on an Android smartphone

That’s all good, but a question remains. WikiWand is a commercial enterprise. So how will they be making money, without “ripping off” the Wikimedia Foundation? That remains to be seen: WikiWand says it wants to add “contextually-relevant ads for textbooks, articles and courses”, with 30 percent of its profits being donated to the Wikimedia Foundation – but only the future will tell whether they can stick to that “education only” ad policy…

Read Full Post »

Over on the Wired website, Cade Metz almost goes crazy about  a new programming language with “a design and a pedigree that immediately set it apart“. The new language is called Hack, and according to the article, “Hack makes it easier to manage code and eliminate errors“…

languages.jpg

Sigh. Come on, Mr. Metz. Hack may be a neat hack, in the eyes of PHP programmers. But Hack isn’t that special, it looks a lot like what PHP should have been from the start – actually, the lack of some of the features of Hack are what made me stay away from PHP for the last two decades. Just compare Hack to CFML (ColdFusion), for example – going from HTML and code in markup to a running page without compilation isn’t that new. And CFML runs on top of the Java Virtual Machine, so you can spice it up with whatever library or programming language you want, as long as it runs on the JVM.

Legacy code, that’s why Facebook needs Hack. Because it would be too expensive to rewrite everything in another programming language. Any other programming language, except PHP++…

Read Full Post »

On the Sitepoint website, Craig Buckler points out how “Average Page Weights Increase by 32% in 2013“.

HTTP Archive -Trends - Total Transfer Size and Total Requests for the period 2012-12-15 tot 2013-12-15

Total Transfer Size and Total Requests
for the period 2012-12-15 to 2013-12-15
(Source: HTTP Archive – Trends)

Craig is not impressed with the numbers, and tries to find the reasons behind the increase. Bloated CMS templates and carelessness (sloppiness?) by the developers may well explain a large part of the phenomenon, but it’s hard to get a real explanation from averages only; more detailed research is required.

By the way, Craig: there’s a difference between an average and a median. When talking averages, there’s no way to tell how many samples are smaller or bigger than the average. So you can’t say: “Approximately half the web sites analyzed will be more obese“…

Going to the source of the data, i.e. the Trends page on the HTTP Archive site, there’s even worse news. If I interpret the “Doc Size & DOM Elements” statistic correctly, there is actually less content in a page than a year ago. So web sites are using more bits to tell less? I guess there’s another possible explanation: advertising may well be pushing out the page content.

Anyway you look at it, the statistics are sobering for us web developers. As Craig correctly notes: “Mobile connectivity and bandwidth continues to improve but it rarely jumps 30% in one year“. That means that web developers are not thinking “mobile”, despite the success of mobile hardware!

If you’re contemplating to (re-)build a web site, you had better make sure that your developers are aware of these statistics – your users might be disappointed if the developers don’t heed the lessons that can be learned from the numbers.

Read Full Post »

It’s worth noting that JavaScript is making quite a few headlines these days, at least in the software developer community. No, it’s no exactly a new language, and I have been using it in many apps on a small scale since many years. jQuery has become an important tool in my daily work (and that of my close colleagues). But these days we’re not just talking about developments added to a webpage; the latest JavaScript talk is about much bigger things.

First (well, to me at least ;-) there was Node.js. In its own words, ”Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications” – on servers, for example. The recently announced blogging platform Ghost is written in JavaScript and based on Ghost. I just read that Groupon is also migrating (parts of) its main web app to Node.js. Not just ”because JavaScript is cool”; Node.js has a high performance reputation in serving web pages, as evidenced again in ”An example of how Node.js is faster than PHP”.

Then came Fargo. Fargo is an outliner from the King of Outliners, Dave Winer. You can try out the essential features of outlining in Fargo’s little brother, appropriately called ’Little Outliner’.

And now I have written the draft of this post in another interesting web application: StackEdit. A wide screen is advisable, but yes, it even works in Chrome on my Android tablet. Well done, guys.

What will be next?

Read Full Post »

You too can experience what is was to surf the web in the early 1990’s. The article “World’s first cross-platform Web browser brought back to life” on Ars Technica explains how. Weird, huh? It shows how fast we humans adapt our lifestyle and expectations to new software – 1992 is not that long ago!

My blog as if in 1992

My blog as if in 1992

PS. I had to cheat a bit: the CSS for the “Line-mode browser” refers to a font called ‘cern’ that is unreadable on my Mac – so I turned it into ‘monospace’. Nor does the “Line-mode browser” like the comments in the WordPress Javascript: what you see is actually the third screen, not the start of the page as you might expect. 

Read Full Post »

Older Posts »