|
|
There's an increasing variety of devices in use today. Even generally rectangular touch enabled devices vary hugely in their physical sizes, aspect ratios, pixel densities, etc. One thing that remains constant across these devices are their users. As a result, ergonomic considerations like touch target sizing, readable text and image size remain constant. Fingers will be fingers and eyes will be eyes! Our bodies are firmly rooted in the physical world, and the interfaces we create should reflect that. Touch too much (or too little?)
|
|
|
|
|
Back in the late 1970s you wouldn't have guessed that this shy young Cambridge maths student named Wilson would be the seed for what has now become the hottest-selling microprocessor in the world. Ninety-five per cent of today's smartphones are built around an ARM processor. The ARM began with Wilson. From Acorn grew a mighty ARM.
|
|
|
|
|
I've been blogging for almost a decade now (wow) and had used many blogging tools. Until that is WLW came out. Since I moved to WLW, I've never looked back. It just works. So you can see why I'm interested in hearing about its future, am an concern that nothing at all is being said about it. Please. Any idea, direction, indication, would be great. Please, let Windows Live Writer live and write its own future...
|
|
|
|
|
There is no smartphone war. iPhone won. As I've written many times, the war now is between Apple and Samsung. Here's where the battle will be fought and won. Android has clearly thrown Google off its game and left others to command the field.
|
|
|
|
|
Of course Android's dead. Oh wait, no it isn't as we now have Ubuntu for Android[^] and a good thing too.
|
|
|
|
|
I would say so too - if I had invested all the money in Apple devices.
Luckily I haven't...
|
|
|
|
|
The development and evolution of the Mozilla browser, from its Netscape-seeded beginnings through the Firefox releases of today, can be fascinating. Numerous changes occurred to the software in terms of technology, features, and appearance; particularly when Mozilla and Mozilla Firefox were both in their infancy and many groundbreaking developments were made. Much of this software was not widely seen or used when initially released. Linking back though the browser history of browser history.
|
|
|
|
|
Once upon a time, Unix was the up-and-coming operating system that was the future of computing. But something happened on the way to world domination, and, while Unix was certainly a commercial success for many years, it has mostly been supplanted by other things - including Linux. It has often been said that Linux cannot suffer the same fate that brought down Unix, but it is worth thinking about whether that is really true. Do Android, MeeGo, Tizen, webOS and other offshoots signal a splintering of Linux?
|
|
|
|
|
I thought Linux was a flavour of Unix -- doesn't it use a Unix kernal? Not that I care, OpenVMS is better.
|
|
|
|
|
The EFF (Electronic Frontier Foundation) has just released a mailing list for coders' rights. Watch Scriptkitty's promo video (it's a bit silly, but what do you expect to promote a mailing list).
|
|
|
|
|
Harvard and MIT are dumping $60 million into an online education initiative. Sounds pretty amazing. Both already offer quite a few CS courses for free online. You can't get a degree online, but you can take the same courses the paying students are taking.
edX Launch[^]
EDIT: Just saw this in the FAQs:
"For a modest fee, and as determined by the edX board, MIT and Harvard, credentials will be granted only to students who earn them by demonstrating mastery of the material of a subject."
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone - Bjarne Stroustrup
The world is going to laugh at you anyway, might as well crack the 1st joke!
My code has no bugs, it runs exactly as it was written.
|
|
|
|
|
Microsoft is today opening a research lab in Manhattan city that aims to benefit from interaction with the academic and tech communities in the metropolitan area, as well as attract new talent to Microsoft, the company said. Most of the initial 15 hires to the lab are researchers from Yahoo Research. [ITworld]
|
|
|
|
|
In this installment we talk to Matthew Brand who, along with Michael Hopke and a few other Champlain College students, recently launched their own game studio. More talk with developers about their backgrounds, projects, interests and pet peeves.
|
|
|
|
|
The best way to improve your systems is by first not doing "dumb things". I don't mean you or your development staff is "dumb", it's easy to overlook the implications of these types of decisions and not realize how bad they are for maintainability let alone scaling. As a consultant I see this stuff all of the time and I have yet to ever see it work out well for anyone. Coffee, cold pizza and clean socks... no, that's what I need to *run* the database.
|
|
|
|
|
I agree with 2 and 3, but not so much with 1.
I have designed databases specifically to hold images and files and I'll probably do so again. His comment "access to the files now requires going through your app and DB layers" is exactly why I choose to store files in a database. There are other reasons to do so as well.
But, it's still a matter of using the right tool for the right job -- you need to really think about what you're doing.
|
|
|
|
|
I don't fully agree with any of them.
1) If the files are of a sensitive nature, store them in a database. It simplifies the security model. Also, if backups are an issue, store them in a different database than the one you backup more frequently. Other files that don't require security (e.g., images) can obviously go wherever, though a CDN is ideal.
2) At my job, we sometimes have to restart the servers because of various issues. Storing session to a database makes it possible for users to retain their session state (so they don't, for example, have to log in again). Storing session out of process might work in some cases, but not if the machine must be restarted. Still, would be nice if we didn't have such finicky servers. *grumbles*
3) I love logging. At my last company, we HAD to log pretty much everything so the data could be audited later. Databases are the perfect place to store logs. If performance is an issue, one can easily store logs on a different database that may even be on a different server. And one should of course abstract out the medium the logs are stored to, so that medium can be changed later. Some employees at my company decided to email every error that happens on our site, but they are so numerous that they are ignored and email is hardly useful for aggregating data (would be nice so we could show which of our servers are most error prone). If we had a proper abstration in place, we could just switch from email to a database. And if we started to log a ton, we could use that abstraction to defer to a queue that bulk inserts into a database.
|
|
|
|
|
My main issue with logging to a database is: how do you log that you can't access the database? I prefer the simplest logging mechanism to avoid as much trouble as possible.
Logs in a file also retain their order even if two entries have the same timestamp.
I write logs as XML, which can easily be imported to a database and analyzed if necessary -- so far it hasn't been.
|
|
|
|
|
That is a good situation a queue would be good for. In the event that logging fails, the queue could keep the logged item and retry later. Or it could write to an alternate medium, such as the file system, email, or the Windows event log. However, logging is not always that essential and not many people put that much effort into it, so it seems like it'd be acceptable to just drop the log event as it'd probably obvious when a connection to the database cannot be made.
Another useful reason to store to a database is when there are multiple servers, such as in a load balanced scenario. Rather than having to remote into each computer, which requires developers be given access to those machines, they can just query a single database. Another situation where logging to the file system would be less than ideal is Azure, as I'm not even sure if you can inspect the file system without writing code to do so and Azure makes no assurance that files will be retained (if the machine goes kaput, the deploy package will be sent to a new machine).
And regarding order, that can be maintained using an identity field.
|
|
|
|
|
AspDotNetDev wrote: a queue
But then how do you log that the queueing system is broken? 
AspDotNetDev wrote: an identity field
Remember who you're talking to.
I'd say that's the wrong tool for the job, or perhaps the wrong job for the tool. I don't (willingly) use identity columns, and I certainly wouldn't for information that is just going to be cleaned out after some period. An identity (or sequence) column on a log table would likely max out much more quickly than one on a customer table, for example.
|
|
|
|
|
PIEBALDconsult wrote: An identity (or sequence) column on a log table would likely max out much more quickly than one on a customer table
There aren't enough hard drives in existence to max out a bigint identity field. 
PIEBALDconsult wrote: But then how do you log that the queueing system is broken?
If you want to account for that, log to an alternative medium (e.g., log file).
But then, what do you do when the alternative medium is broken (e.g., some process locks the log file or deletes the containing folder)?
|
|
|
|
|
I agree with your agreement. Not so much with #2 though. What the author calls ephemeral data, usage stats, metrics, etc. The reason to store such information is to be able to analyze it. It is a matter for architecture and design of an application as to what is necessary and what is not.
Failure is not an option; it's the default selection.
|
|
|
|
|
I wouldn't take this piece too seriously. There are no hard and fast rules for what you store in a database - you make the decisions based on the job at hand.
Also I disagree in a big way with point 1 - it's perfectly fine to store images and files in a database. And in fact you should do so in many cases - because you get transactions, rollbacks, atomic operations etc. Also, when you back up, you have your files as well - rather than having to copy files from an arbitrary folder from one server to another.
|
|
|
|
|
Oh man. Not another one of these "my advice for my type of work is gospel and works for everyone" type articles.
1. Storing BLOBs is sometimes the *only* practical option you have.
2. What if your ephemeral data generates, itself, important data that is persisted? A crude example is session data: storing it in a database means that when things are weird you can perform sll sorts of queries on the sessions and spot malicious activity
3. I don't even know where to start on this one other than to say that if you want to store logs in flat files then why are you storing them at all. If your logs are small enough that you can manually scan them every day then fine, but if you have serious data then log only if you need to, and the #1 reason to log is so you can search the logs later, and, well, that's what a database is really, really good for.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Chris Maunder wrote: you can perform sll sorts of queries
Sounds... er... efficient.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
