If you have found a use case for Big Data, but have been putting it off because you don’t want to have to learn Hadoop and Map/Reduce, I encourage you to look at Oracle Big Data SQL.
This product allows you to use regular SQL to query data sources across relational, NoSQL and Hadoop data sources. As usual with Oracle, it has been cleverly optimized to join data in the most effective way.
For now, it requires you to buy a couple of racks of Oracle hardware (an Exadata and a Big Data machine), but Oracle has announced that it will be available as a cloud service as well.
I’m giving this an up arrow on my Oracle Trends list.
I was standing in line at the checkout while the cashier was frantically trying to scan a couple of steaks. He gave up and tapped in a long product code, still with no luck. Then he picked up a phone and called someone and had a long and agitated conversation while irate customers were piling up behind me. Finally, he managed to enter a code that was accepted by the system. My steaks showed up on my receipt as “Misc. meat”.
Why would you let your system get in the way of your work like that?
The business benefit from registering my steaks on the exact right code will is minuscule – after all, supermarkets are proudly talking about the mountains of “big data” they are gathering. On the other hand, the business disadvantage of annoyed customers is real.
Do your systems get in the way of your end users? Field studies are the only way to find out. If they are, provide something like the “999999 Misc.” code that well-run supermarkets use. Don’t let your organization grind to a halt when reality doesn’t match the system.
I’ve found that many of the people I work with in IT are worried. Worried that their code wont perform as required, worries that their boss don’t like them, and worried that their job is going to be taken over by someone being paid half as much as they are.
The number one antidote to worrying is knowing you are good. And a good way to get good is to read books. Not blogs, not forums, not random comments. Real books. I’ve written several, and the process that goes into creating a book creates much higher quality than random blog posts. If you don’t have any specific IT book in mind, I’d recommend a classic:
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
I recently wrote a blog post about why a smart watch is likely to kill your productivity, and today Scott Adams’ Dilbert proves my point:
Wearing a constant source of distraction on your wrist is a bad idea.
Experienced IT professionals know that it is very rare that something is as simple as it first seems. Thus, the actual implementation shows to be harder than expected. But the business value can also change during implementation – sometimes it gets better, sometimes it gets worse.
1:1 conversions achieve little business benefit and cloud projects often much less than promised. But a well-run technology migration project can actually harvest more benefits than you initially expected.
This illustration is from this week’s edition of the Technology That Fits newsletter. If you want fresh insights into IT delivered to your mailbox every two weeks, sign up here: http://eepurl.com/0fpvT
I love gadgets at least as much as the next tech guy (or girl), but I have a hard time finding a use case for smart watches like the Apple Watch. If you have spent any time at all investigating productivity, you will have found that interruptions are the bane of efficient work. It’s bad enough that we have laptop, tablet and phone to constantly beep interruptions – why would I want a fourth device to do this?
I’ve carefully disabled notifications on my mobile devices and run my Mac in “Do Not Disturb” mode. I can’t see any reason to strap a device to my wrist whose only purpose is to disturb me.
Fortunately, it seems that many people are wising up to the fact that the Apple watch is a solution in search of a problem:
I challenge you to come up with a reasonable use case for wearing a smart watch all day.
The other weekend, my Triathlon club was hosting one of the events in the Danish Championship series. As you might expect, there is a lot of stuff to prepare in a sport that requires a swim route, a transition area (T1), a bike route, another transition area (T2), a run route and finally a goal area. I was part of the team preparing T2 where participants change from bicycling to running. For that, we needed to set up a lot of these yellow barriers and link them together:
I was on the left side (where you notice a double barrier). We finished before the other side even though we were fewer people and had twice the amount of work. Why? Because we took one minute at the start to find out how the barriers hook together. The other side just started working, and had to life each element to hook it onto the next.
A great many things can be done in several ways. Before you start, take a moment to reflect on what the consequences of each way is. You’ll save a lot of time.
There are two approaches to security:
- Trust, but verify
The first places hard restrictions on what users can do. Advising development teams, I very often find that development workstations are locked down so tight that a developer can’t install a needed utility without logging a service request. The enforcement strategy always comes with a cost in lost productivity, but nobody bothers to count this cost.
The second places few restrictions on what users can do, but has a rock-solid audit function and people to actually monitor this. This approach doesn’t suffer the loss of productivity that enforcement does, but it does require you to generally trust your users to do the right thing. The problem with the trust & verify strategy occurs when organizations do not truly monitor what users do. This can allow malfeasance to go on for too long.
Make a decision which way you want to go. If you go with enforcement, make sure to calculate the cost. If you go with trust & verify, make sure you truly implement the “verify” part.
What does an e-mail weigh? Nothing, you say, it’s just bits in a computer somewhere.
Wrong. Each e-mail you allow to pile up in your inbox is weighing you down. It’s another item on your to-do list, in addition to all the other to-do lists you have lying around on post-it notes and in half-heartedly maintained task management systems.
Every e-mail in your inbox is an open loop and a load on your brain. You need to establish a procedure for getting your inbox to zero every day. You don’t have to do everything, but you need to have processed everything and have placed it into a system where you are sure nothing gets lost.
Personally, I’m using SaneBox to help me keep my inbox empty, but any procedure or tool is good. Free your mind, empty your inbox.