A few days ago, Radu Drăgușin discovered a data leak at the IEEE servers, enabling him to download about 100.000 plain text keywords (probably mine as well).
On the one hand it shows how critical it is to consider the security off your system, nevertheless if you are a small company or a worldwide organization such as the IEEE. On the other hand it showed that even large organizations you never thought of this might face such fatal security leaks.
However, Radu went ahead and (a) decided not to share the information he gained through this security leak with public (big kudos for this decision), (b) to prepare various statistics on ieeelog.com based on the information (which are indeed interesting without revealing traceable information about individuals) and (c) to inform IEEE about the leak (also kudos for this). As a result you can say, he was quite responsible with the data he received and at least e followed some of the principles, provided by the IEEE Computer Society Code of Ethics.
One result of his analysis is the fact, that about almost 300 users are using the password 123456, reminding me Mel Brooks epic Star Wars parody Spaceballs, Dark Helmet saying
“So the combination is… one, two, three, four, five? That’s the stupidest combination I’ve ever heard in my life! That’s the kind of thing an idiot would have on his luggage!”
As a result, I went straight to my IEEE account and changed the password. Luckily, it was a password not used for any other site beside the IEEE. Said that, if you have an IEEE account, it probably is a good thing to go there directly changing yours as well if not already done.
And Radu, whenever you ever read this post, if have the chance please have a look into the log files and let me know if the user aheil is listed there as well.
“Important: The Google Feedburner APIs have been officially deprecated as of May 26, 2011 will be shut down on October 20, 2012.”
For all readers of this blog subscribed to the google Feedburner feed, it has not been available using the URI http://www.feedburner.com/aheil probably providing a 404 error code for the last few days. The Feed Stats dashboard already shows that the feed has subscribers anymore.
I used Feedburner even before acquired from Google. It was a great way to aggregate various sources of information on the web. Even with a deprecation time of three years, it is quite a loss as Feedburner provided a great way of mashing up data sources. Probably this service did not generate sufficient revenue for Google…
After several years spending time (including writing a book) in the field of intelligent environments, ubiquitous and pervasive computing, I decided to brings some digital life in our home. As winter is coming, I am looking forward to finally start some home automation project called Hack The Planet.
The project itself has two goals, at first it should be fun. Being a computer scientist, geek, nerd, developer gadgeteer this is obvious. Second, I want to document how to deal with a project, abut the artifacts, the process, pans, restrictions, chances and threats hat might occur. In this article, I am going to discuss the very first thoughts of this project as part of the project initiation.
First of all there needs to be a vision. I am not talking about the business case, yet, just a very first vision statement.
“For me and my family, I want to set up our home in a way, I can remotely monitor and control most of the electronic and mechanical devices any time during the day, at any place where I am currently located as long as I have a decent internet access.”
“For me and my family who want to monitor and control our home remotely, Hack The Planet is a home automation system that is easy to use and extensible. Unlike available off the shelf products our product integrates hard- and software components from various vendors and can be easily extended with new techologies.”
That’s basically a very broad statement, however, for the near future this will lead the direction. I have seen many projects failing, because of the project management keeping the vision under any circumstances.
Second, I invested several hours if the project as I have it in mind is feasible at all wich is a major constraint. Are the devices I have roughly in mind available as off the shelf components, will they be within the project budget (i.e. can I afford them?), can I connect/hack the available hardware, are the serious technologies compatible or can I at least connect them in any way?
Beside creating a business case, drilling down the vision into scopes should be the next step before continuing with the project.
Last year, I became a backer on Kickstarter. I was looking for a while how to support great ideas in a way with relatively little risk. I wasn’t looking for sort of business angel backing, was looking how it is possible to help folks with great ideas and visions to achieve their goals. The Elevation Dock for iPhone was the first project I pledged and as plus, I received a reward, one of the first docks being produced.
The dock arrived via standard mail, i.e. in Germany it was not delivered with DHL as parcel it came by snail mail, though. Fair enough, as only a few dollars have been added for international delivery.
For international delivery the box was fairly packed. Could be better, as it seems that the box moved around in the box a lot. If it would contain breakable parts, this would be probably fatal. However, considering that some human put a lot of effort into packaging this thing for me, that’s fine. I guess there is a lot of improvement in he future.
The box of the Elevation Dock quite nice. White, sort of apple style, took me a few seconds how o open it, I tried first to push the inner box out of the sleeve before I realized that you can simply flip the box cover.
The box itself showed that it traveled some thousand miles and that several people moved the parcel from A to B before it finally arrived here. Actually, I don’t care, at this moment I am just interested in the content of the package.
The dock, which is surprisingly heavy for being made from anodized aluminum, comes with a pre-mounded USB cord. It’s only a few inches. A longer replacement cable is provided if you want to place your dock somewhere away from your USB hub, power supply or computer. Kudos for this add-on.
Actually, I haven’t seen this in the first place, the dock comes with a hex wrench. I think this piece does not cost that much but it#s great for being included. It’s in fact the only tool you need to replace the USB cord. What it does not come with is a AC adapter. While there is a spare place in the package it seems there are no adapters in the Kickstarter rewards added. Maybe this was announced in one of the various mails send during the creation and funding process and I missed that one. However, the empty place in the box labeled AC adapter is quite an indentation there will be a adapter in the docks sold regularly in the future.
The overall manufacture quality is impressive. The surface is well done and all parts fit perfectly. Turning the dock upside down, you see how well the parts fit. The black bumper within the dock can be turned to fit iPhones with cases into the dock. Also this part fits perfectly and is easy to change.
The rubber stands are well made, on various surfaces the dock comes with quite some friction.
As my new iPhone 5 is still on its way, I tried the dock with my not-nearly-retina-and-meanwhile-slow-like-hell iPhone 3GS. Fits perfect. In fact, it fits so well that you have to hold the dock once you want to pull the iPhone from the dock. We have tried this with the iPhone 4 as well, and as promised by Elevation Lab, the dock is a low friction dock. It is awesome how easily you can remove the iPhone 4 from the dock. No need to fix the dock at all, the iPhone 4 just slips out of the dock. Very well designed. That was the original reason I supported the dock.
On the photography above you might have seen a small spot on the left edge of the dock. This is really bad luck, as the quality of the dock is so high, I really got one with a small mark on the left top edge. Maybe this happened during packaging, as I cannot imagine this happened during transportation. As most of the packaging and quality assurance process in done by hand yet, this might happen. I bet the process for controlling the quality of the devices will improve over time.
As a very last step, I tried to exchange the cables provided with the dock. Opening the dock with the hex wrench works quite smooth. Opening the bottom of the dock, I found this surprising note. It should be obvious not just to bull on the cord how some moron, however, it is a great idea to provide such a note to the user. Many people would probably damage the connector while swapping the cords.
Finally, I had a look at the connector. Again, very high quality. The USB cables have micro USB connectors. Surprisingly, the dock connector is mounted using hex screws. Said that it should be possible to change the bolt in connector. In fact, Elevation Labs recently announced that they are currently working on a exchange connector for the new iPhone 5.
I am quite happy being a backer of this project. The quality of the device is high standard, the updates on the project by Casey Hopkins have been great and regularly, and finally receiving the reward is just awesome. Now I am looking forward for the new connector. The time Apple announced the the new connector, the design and production of the dock has been already in full progress. Also many people complaining about the dock having the old connector, one should bear in mind, the docj was designed as a low friction dock for the iPhone 4/4s. And as far as being evaluated it is as promised.
As a resume, Elevation Labs will be definitely one of the gadget providers I will keep on my favorite list for the future. As they already announced the design of a new dock with improved sound capabilities and the development of the new connector I hope that business goes well and they will supply a lot of nifty gadgets in the future.
I am probably the last person in the .NET community who figured out how to disable the Visual Studio 2012 Metro design upper case menus. I haven’t had a chance to work a lot with Dev11 yet, so I was not bothered too much by the new design. After working a couple of hours with the new IDE, I was quite annoyed by the new upper case menus.
It seems that Richard Blanks was the first who figured out how to disable the upper case menus in VS 2012, looking nice and capitalized.
As I love to do things automatically when possible and hate to fiddle with the Registry Editor, I set up the registry key to change in a small script. Just rename it to .reg and double click the file.
Windows Registry Editor Version 5.00
Recently, I discussed a lot with friends and colleagues about new mobile devices. Using Windows Mobile for years, I switched to Apple’s iPhone 3GS three years ago. Before, I talked quite a lot with a friend who recently bought one at that time.
Before, I used an iPod for listening to music and Windows Mobile devices such as the HTC Hermes or the HTC Touch Pro for quite a few years. Over time, I got annoyed by always carrying two devices, two power plugs, two connector cables and by managing at least two different applications to sync both devices. Eventually, my decision to buy an iPhone was driven by quite rational thoughts.
I was pleased with the hardware quite a lot, never worried about the processor, ram or other components of the device. The only drawback for me as an developer was the fact that you cannot simply deploy your home brewed application to the device.
I skipped two generations of the iPhone, finally rethinking of getting a new device. What shall it be? Meanwhile, I am quite off the track developing for Windows Mobile. Also, the hardware fragmentation for Windows devices is quite a bit. Similar situation with Android based devices. Which one is the reference hardware to buy? While the idea of developing for the Android platform is tempting, there are more facts to consider.
After three years, I have to admitt, the ecosystem lock in is quite a reason. IPad (first gen but with 3G), an almost retina but bought a few months to early MacBook and quite a lot of periphery to use with my devices is a good reason to stay. Nevertheless, with the new Lightning connector many peripheral devices became obsolete.
Much more than the hardware lock in is definitely a data lock in. Dozens of apps with your data, synced address books and calendars, lifelogging and quantified self data collected over the years is a good reason to stay with the current platform.
With the release of the new iPhone there is a lot of making-fun-of-the-new-iphone going on, however considering the facts above you see there are simple reasons to stay with a platform. This is definitely a goal of every manufacturers, and Apple plays this this game very well.
Looking at the new hardware, iOS 6 as well as the new Mac OS, there is no rocket science, there is no Star Trek communicator and no universal translator comming with new iPhone. There is no revolution, simply a technological evolution of a long designed system. A system that grew five generations.
Personally, I think a steady evolution of technology is worth quite a lot. I don’t want to migrate all the data, I don’t want to worry about the hardware to buy, I don’t want to learn new user interfaces and usability concepts for now. I want a device being part of my daily (business) life, easy to use, sitting in my pocket being available when needed. With the current evolution of the iPhone this should be possible for the next one or two hardware generations.
Said that, it will be a 64GB iPhone in white for me while it will be a Nokia Lumina 900 or a Google Galaxy Nexus for others due to the same or similar reasons mentioned above.
Over the last few days I (re-)thought a lot of the role of an architect in a Scrum team. I tried to avoid to read about other opinions and just thought of my very own experience over the last few years in agile teams.
There should be an architect in your organization, however, he should not be part of the Scrum team itself. Scrum is about the development process in your organization or project and as such is it a required constraint for the architecture to develop.
The architect deals with non technical issues, so called facts of life, politics, organizational constraints, budget restrictions and so on. No team member could address thees in the regular development sprints.
As an architect one should analysis and manage risks – again nothing a team member could do during a regular two or four week sprint. Considering risks probably begins long before the team is Assembled and t he project is started. In fact, as an architect one could even point out the project might not doable due to various reasons.
An architect has to run in iterative cycles as constraints change, customers come up with new and modified requirements and organizational goals mit shift over time. All this might require some redesign or evolution of the architecture. However, these architectural cycles are not bound to the development cycles of e team. They are more related to the business, customers and organization.
The architect is a technical leader. Maybe by prototypes or bullet tracing he shows how hard parts of the system can or will be addressed. As such he provides a base to the team to better estimate the complexity of the upcoming implementation. Eventually, as architect it is important to address the hardest issues first whiled the Scrum team addresses the tasks with the highest business value first.
As an architect you teach and coach your team. In Martin Fowler's article Who Needs an Architect?, published in IEEE Software, Fowler points out, that an good architect mentors his team, not sitting in his ebony tower.
Dealing with uncertainty is probably one of the most underestimated aspects of the dayjob of an architect. In the role of an architect, I have to make decisions under a high degree of uncertainty. As many aspects of a project change over time, early decisions are uncertain. However, as an architect, you have to consider the consequences of these decisions. It's a major part of your job to consider risks and work on plans wether any event occures that affects your project both, a a threat or a chance.
I contrast, in the role of an developer, you should not be confronted with uncertainty. You have a tough schedule and proper tasks to fulfill, Technologie and tools are in place and in the best case you have all the knowledge to perfomreyou task. If the requirements for your task are not clear, you probably cannot fulfill it.
I have experienced this very issue during the last few years several times. Most of the time this was caused by the lack of an architect or the position of the architect was not dealing with the role of the architect in a proper way, most of the time writing code themselfs.
Therefore, do architects write code? This might be one of the most discussed topics for software engineering. Personally, I have experienced both, architects writing (productive) code all the time a well as architects never worked in product development. As an architect you probably should provide certain coding skills. Earning your street cred before becoming an architect is inevitable. You must be able to read, understand and improve the code. However, you have to delegate the actual task of building the code base to others. Nevertheless, you probably have to improve your coding skills permanently. Therefore, an erchitect must be able to write excellent code, however he should not write the bits delivers despite prototypes and tracer bullets.
As a fact, running an agile environment does not supersede an architect. Neither does it reduntize the overall product planing and designing process. The architect is not part of the Scrum team as he does not deliver within the Scrum team. He is in a position existing before the Scrum team is assembled, he leads the direction and can hold an consulting position for the team. However, the a architect is not part of the sprint plan and as he is not part of the Scrum team as such.
Looking at myself, I see how different I work nowadays with devices than almost 30 years ago. In the early days of personal computers you spend a lot of time in figuring out what you actually can do with your Commodore C64 or your very first 286 hardware while knowing each component's specification. Nowadays it is simply about the available software. Most of the users probably do even not know about any technical details of the device they are using beside if it is slow or fast.
If you look at professionals who use computers, they often use one specific application, which maybe is shut down only once at the end of the week. Personal users probably don't know that there are more applications on the computer than the web browser.
As computer professionals we tend to forget to think about the why others do use computers. We see the full potential of the latest programming language, the computing power, the maximum available bandwidth and all the fancy features we know about.
Tablets such as the iPad or the new Nexus are great for end users. Quite intuitive to use, and no need to worry about the hardware. Whatever users want to to, they simply have to find the right app. I fact, I use my iPad for many common tasks, even for writing, blogging and editing images the apps are meanwhile quite well done.
Specialized applications used by various professionals do not need a fully equipped personal computer. Ever looked at a doctor's place? In every surgery you might find a personal computer running often just one program. Or have a look at a common electronic it furniture megastore. Each information desk will probably has one personal computer running one program on it. Often, these programs are typically host applications where the client continually requests information from a server application
There is no reason to put a fully equipped computer in every room for a single application. Either a thin client or some lightweight tablet might the answer here. Either a web hosted application or a small application communicating with a server (e.g. In the cloud) might be a good solution.
As professional software architects and designers we should consider this while designing application even if stakeholders still request old fashioned desktop applications.