diego.fernandez on Wednesday, May 21, 2014

Prototyping with HTML

0

“I believe that if we think first about people and then try, try, and try again to prototype our designs, we stand a good chance of creating innovative solutions that people will value and enjoy.”Bill Moggridge, Designing Interactions

Prototyping is a key practice of design; it allows designers to visualize, evaluate, and communicate.

To explore design ideas, the prototype must be quick and inexpensive. It must suggest and explore these ideas, rather than confirm them. That’s why some HCI researchers like Bill Buxton, prefer the term sketch over prototype.

Paper prototypes have a unique feature: the return of investment, in terms of learning, is extremely high. It takes hours or even minutes to be created, and in exchange you can receive valuable feedback.

If you prefer digital means, tools like Balsamiq or Pencil, imitate the sketchy nature of a paper prototype. The term low-fi prototypes is used to refer to this kind of prototypes, regardless of them being on paper or not.

Tip: to quickly clean up scanned sketches, use the adjust levels option, included in most of the photo editing applications.

Last month the massive Heartbleed security vulnerability was exposed. Three weeks later a security flaw in Microsoft Internet Explorer was revealed. It seems as though every few months there is news of a security breach or vulnerability. As more and more business is done online, in the cloud and through SaaS providers, how can you be sure the applications you and your business use are safe? Using the Heartbleed vulnerability as a case study, this article will examine what went wrong, as well as what you should expect from a SaaS provider, before, during and after a security event.

What is Heartbleed?

Heartbleed is the commonly recognized name of an exposure identified in a critical Internet security software package called OpenSSL, the most common transmission encryption software package used by Internet servers worldwide. This vulnerability allows an attacker to craft keepalive messages in such a way as to force a server disclose its short-term memory space. Since a server’s memory often contains personal, confidential information, such as user passwords or credit card numbers, the attacker could obtain that information. More severely, the server may also inadvertently disclose to the attacker its own private encryption key, which then allows the attacker to subsequently listen to all communications with that server, even without using the Heartbleed vulnerability. The nature of this attack is such that it leaves no traces, and is practically invisible to common detection mechanisms (although now that it has been exposed, signatures for it are becoming available for popular intrusion detection software).

Damian Sima on Wednesday, May 14, 2014

Near Real Time Sync with Batch

0

The idea of this blog post is to give you a short introduction on how to do Real time sync with Mule ESB. We’ll use several of the newest features that Mule has to offer – like the improved Poll component with watermarking and the Batch Module. Finally we’ll use one of our Anypoint Templates as an example application to illustrate the concepts.

What is it?

Near Real time sync is the term we’ll use along this blog post to refer to the following scenario:

“When you want to keep data flowing constantly from one system to another”

As you might imagine the keyword in the scenario definition here is constantly. That means, periodically the application will move whatever entity/data you care about from the source system to its destination system. The periodicity really depends on what the application is synchronizing. If you are moving purchase orders for a large retailer you could allow the application a few minutes between each synchronization. Now, if we are dealing with Banking transaction you’ll probably like to change that to something in the order of a few seconds or even a hundred milliseconds, unless you really like to deal with very angry people.

Uri on Tuesday, May 13, 2014

APIs Can Be Copyrighted… Now What?

6

The battle between software giants Oracle and Google hit close to home again last week, when a Federal Court of Appeals overturned a 2-year-old ruling by a lower court and established that APIs are entitled to copyright protection. The first reaction from most people is: how strange! After all, APIs are just the specification of how a software system or service behaves – call it this way, send it this information, get back that information – so how is that possibly something copyrightable? It’s not like a book, or a painting, or even software… And the second reaction, from many in the API world, is: no!!!

Overcoming challenges with integration is no easy feat. Data driven by SaaS, Cloud Computing and Mobility results in an abundance of customer information. The challenge no longer lies in obtaining buyer information, but in integrating all of the data endpoints.

Integration across disparate systems is crucial to better understand customers, observe behavior, analyze data and create the optimal customer experience. However, not all marketing tools are designed to communicate with others. A whopping 500 billion dollars a year is spent trying to solve this problem.

Crimson Marketing, experts in marketing technology, sat down with MuleSoft’s Mahau Ma, VP of Marketing to chat about this problem and how it manifests itself:

  • MuleSoft for example, uses over 100 SaaS applications, a website on Drupal, a blog on WordPress, interactions though Marketo and Salesforce, a content engine on Insightera, and customer forums, to name just a few demand generation tools.
  • Retail “Omni Channel” operations: A company might have SAP at the core, legacy EDI systems, modern API technologies, social marketing channels, mobile channels, an E-commerce engine, a payments engine and interactions in a brick and mortar store as individual components of their product marketing machine.
  • The Healthcare industry: Having a 360° view of the buyer can literally be a matter of life and death. Ma details a case where his top five Pharma clients had to maintain product marketing data from over 8,000 websites, social channels, mobile apps and physician channels to ensure not only a great buyer experience and optimized demand generation, but also to avoid potentially fatal errors.

Listen to the entire podcast »

Templates are simple solutions to start building your own integration applications that help to accelerate ‘time to value’ for your company. We focused on creating templates in a particular way to meet a high quality bar and to help you maintain that bar when you choose to extend our templates or build your own. In this post, I wanted to run you through our principles, structure, and provide some advice when using one of our templates.

There may well be 50 billion device coming, but the most exciting things in the Internet of Things are the ones you can hack. I’ve developed a new weekend hobby of connecting and hacking devices. Here are my top 5:

Philips Hue
These connected lights bulbs have an HTTP API that is really easy to use and allows you to control single and groups of lights. You can control the colour range, brights and hue of course.  Furthermore your partner will love the pretty colours and you’ll convince your kids you can do magic.

 

Google Glass
Yes this is the device that is paradoxically cool not cool. It has a REST API that gives you access to post items to the Glass timeline and subscribe to location and updates from it.  The REST API is pretty limited, but luckily Glass runs Android and has a GDK for writing apps for the device itself, which greatly extends the possibilities.

In this post I want to close the loop on introducing you to the last of the five initial patterns that we are basing our Anypoint Templates on. I’m sure we’ll continue creating templates and we’re going to continue discovering new data integration patterns. If you are just entering at this post, I would recommend that you look through the previous four posts to understand the other patterns. I generally do not repeat things that overlap between a patterns, so I would encourage you to work your way through all five posts if interested.

Pattern 5: Aggregation

What is it?

Aggregation is the act of taking or receiving data from multiple systems and inserting into one. For example, lets say I have my customer data in three different systems, and I wanted to generate a report which uses data from all three of those systems. I could create a daily migration from each of those systems to a data repository and then query against that database. But then I would have a whole other database to worry about and keep synchronized. As things change in the three other systems, I would have to constantly make sure that I am keeping the data repository up to date. Another downside is that the data would be a day old, so if I wanted to see what was going on today, I would have to either initiate the migrations manually or wait. If I set up three broadcast applications, I could achieve a situation where the reporting database is always up to date with the most recent changes in each of the systems. Still, I would need to maintain this database whose only purpose is to store replicated data so that I can query it every so often. Not to mention the number of wasted API calls to ensure that the database is always up to x minutes from reality. This is where the aggregation pattern is really handy. If you build an application, or use one of our templates that is built on it, you will notice that you can just on demand query multiple systems merge the data set, and do as you please with it. So in our example above, you can build an integration app which queries the various systems, merges the data and then produces a report. This way you avoid having a separate database, you can have the report arrive in a format like .csv, or format of your choice. Similarly, if there is a system where you store reports, you can place the report there directly.


So far, in this series, we have covered Migration, Broadcast, Bi-Directional Sync, and today we are going to cover a new integration pattern: Correlation. In an effort to avoid repeating myself, for those who are reading through the whole series, I will omit a lot of relevant information which is shared between the patterns that I have previously covered. I urge you to read at least the previous post about bi-directional sync as correlation can be viewed as a variation of bi-directional sync. Also, note that this is the only one of the five patterns that we have not released any templates around, this was done in the interest of time, and due to the belief that this may be the least common pattern for Salesforce to Salesforce integration. We are however looking to create and release templates using the correlation pattern in the next few months.

Pattern 4: Correlation

What is it?

The correlation pattern is a design that identifies the intersection of two data sets and does a bi-directional synchronization of that scoped dataset only if that item occurs in both systems naturally. Similar to how the bi-directional pattern synchronizes the union of the scoped dataset, correlation synchronizes the intersection. Notice in the diagram below that the only items which will be meet the scope and synchronized are the items that match the filter criteria and are found in both systems. Whereas with the bi-directional sync will capture items that exist either in one or both of the systems and synchronize. In the case of the correlation pattern, those items that reside in both systems may have been manually created in each of those systems, like two sales representatives entering same contact in both CRM systems. Or they may have been brought in as part of a different integration. The correlation pattern will not care where those objects came from, it will agnostically synchronize them as long as they are found in both systems. Another way to think about Correlation is that is like a bi-directional sync that only does updates existing matches, rather than creates or updates.

CONNECT 2014 is only a month away and the tempo is picking up pace. It’s going to rock and here at MuleSoft, we’re getting pretty excited! 

Come see how you can amplify innovation:

  • Hear from thought leaders from the most innovative companies (Salesforce, Tesla, Box, Stripe and more!)
  • Gain insight from over 15 customer case studies and 30 unique breakout sessions – we’ve got everything from business transformation strategy to hands-on product demos and workshops.
  • Problem-solve with MuleSoft employees and technology partners

And the icing on the conference cake? How about seminal rockers … CAKE! Come party into the night and be a part of the integration revolution! 

Still not convinced? Check out this video and start daydreaming today »

Follow the conversation on Twitter with #CONNECT14