LavaBlast Software Blog

Help your franchise business get to the next level.
AddThis Feed Button

Stop trying to build the next Facebook

clock November 9, 2010 12:58 by author JKealey

facebookyouredoingitwro There are a number of strategies to build a successful software startup but my favourite is to focus on a niche. Find a very specific group of people with a common problem and solve it well. As software startup founders, we have the luxury of picking very narrow niches (and still surviving) while non-software businesses need lots of capital. For example, you can build software to connect potato growers with buyers for a fraction of the upfront/ongoing costs of launching a business that provides innovative farming tools to potato farmers.  (Yes, potatoes are awesome.)

What’s ideal about niches is they allow you to start your business and survive, if you’re serious and dedicated. When leaving the comfort of employment and starting their first business, I feel that survival is all you should worry about. You’ll never become filthy-stinking rich and your face won’t be on the cover of any magazine, but you’ll make a living. Your lifestyle will be completely different: you’ll be happier because of your flexible schedule or, more importantly, your work will have a direct and visible impact on other people’s lives. Take this time to learn about being in business and grow as an individual: that’s all that is important. To use an oft used insect-related analogy, you’ll emerge from your cocoon as an entrepreneur after a couple years of trial and error.  (Other ones include Be A Cockroach but they smell.)

Now kick the training wheels off and really get started. You’ve gained some experience, built something and can start thinking about growth. You’re now in a much better position to decide what should be done to turn your business a multi-million dollar company. Most probably, you will have radically changed your original plan based on what you’ve learned. The dynamics of the game have changed: scalable growth, not survival, is your goal. 

In a niche, you can determine who to talk to (potential clients and partners) and can do so in a structured manner. Without one, you’re wandering. This is critical: you shouldn’t be building anything without getting validation that it is the right thing to build. Although we all like to think about software as innovative, the fact is that the technical risk is very low for most software startups; the real risk is market risk. Know the answer before starting your business: can you build something people will buy and can you sell enough of it to make it worthwhile? You can’t discover this on your own; lay out your idea on paper and talk to your target customers about it.

  • Don’t fool yourself into thinking your ideas are unique or that you’re spectacular.  Ideas are a dime a dozen; everyone has the same ones.
  • Given enough money, you can build and sell anything. Know how much you have and what you can accomplish at your size. Drop the ideas you can’t properly build or commercialize and move to something realistic. I’m sure you could genetically engineer unicorns if you had a billion dollars, but do you see Mark Zuckerberg peddling unicorn meat?.

This brings me to my main point: stop trying to build the next Facebook. By this I don’t mean “avoid building social networks” but rather “stop trying to be an exceptional anomaly” because you will fail. You’re not a contestant on “Who wants to be a billionaire?” and the odds are stacked against you. Anomalies are, by definition, rare. However, everyone has heard of these companies, making them appear as within reach and misleading hordes of would-be entrepreneurs. You should have large scale ambitions, but past a certain point you become a dreamer, not an entrepreneur.

Go niche. Work hard. In a couple years, you may be able to attack the larger market you originally had in mind because you now have both the expertise, the contacts and the funds to execute on your original larger-scale idea. Step out of the dream, enter reality and you may be able to set the stage to actually achieve what you dreamed about. Otherwise, you’ll end up like one of the weirdos screaming they invented Facebook in front of a local pub on St. Patty’s day. Additionally, if The Social Network is accurate, Facebook was actually niche-specific (Harvard only) in its early days.

I smile when I see businesses with niche focus and would have liked to have seen more at the latest Ottawa DemoCamp. Even if the product/niche evolves over time, I believe they have a greater chance of survival. Here are a few sites that exemplify the strategy:

Astute readers may have noticed that the above list includes a link to our software product for the franchise industry: FranchiseBlast. We spun-off some content from our corporate website onto its own website for marketing purposes and to reflect our current focus on software for mobile/service-based franchises. More on this in an upcoming blog post.

I’d like to know your thoughts on taking these types of niche businesses to the next level. Seems like the most common strategies are:

  • Same product, different vertical [if the company focuses on scaling product sales]
  • Generalization to many simultaneous verticals [same as above, but harder to accomplish]
  • Product diversification (new products) in same vertical [if the company provides value-added services in addition to a commercial product]

Are there any good success stories in this area? Spectacular failures? You tell me!



Lead To Win Program Review

clock June 28, 2010 08:41 by author JKealey

 

IMG_4322 Over the past few weeks, LavaBlast has been participating in the Lead To Win program in Ottawa. At a high level, people starting high-tech businesses in the region are invited to apply to the program which helps them get to market faster and/or accelerate their growth. After a number of filters, the cream of the crop become a part of an exclusive business ecosystem of local companies. I joined without knowing what I was getting into but truly enjoyed the experience. Since one of my critiques of the program is that the website doesn’t do a good job communicating what the program is or what the benefits are, I thought I’d write a short post on the subject!

Who can apply?

  • Anyone who is serious about starting a business than can generate six high-tech jobs over the next three years.

What is the process?

  1. [filter] You submit a written application
  2. [filter] You pitch your business idea to a board of reviewers before being let in.
  3. Phase 1: You attend three consecutive twelve hour days (8am to 8pm) of hands-on presentations on various subjects (business idea, differentiation, sales, marketing, etc.).
  4. [filter] You pitch to a diverse group (Founders, Funders, Professionals, Education, etc.) and are hopefully invited to Phase 2.
  5. Phase 2: You attend three more consecutive twelve hour days of hands-on presentations (finances, accounting, legal, cash flow, sources of funding, etc.)
  6. [filter] You pitch to another group of reviewers and hopefully graduate into Phase 3.
  7. Phase 3: You’re part of the ecosystem
  8. [filter] If your business is obviously going nowhere, you get kicked out.

 

Are the presentations any good?

Definitely. They’re a lot more hands-on than what you’d find in university courses. The 60 to 180 minute presentations are:

  1. Given by credible individuals in diverse groups (local entrepreneurs, angel investors, venture capitalists, service providers, academia, lawyers working for “patent trolls” :), etc.)
  2. Of tons of different subjects (there is more than enough diversity in the material to justify a 6-day commitment)

 

Why are there so many filters?

  • To ensure that only high quality businesses are in the ecosystem.

What are the benefits?

  • Strengthening the plan: You get validation that you aren’t crazy and that your plan makes sense.
  • Networking: When 30+ businesses are put in a room together for six twelve-hour days, bonds are created between the companies. You get to know like-minded people much faster than at random networking events. One major part of the concept is to build an ecosystem that collaborates and generates leads for each other. Moreover, you meet tons of other experienced individuals that contribute to the community (networking is not limited to other startups).
  • Increased credibility: There are dozens of government programs to fund startups and, because they know the value in the program, you’ve already proven yourself to them before starting discussions.
  • Joint ventures: Apparently [have yet to live through this], businesses collaborate on larger opportunities brought into the ecosystem.

Review

IMG_0575 What I disliked the most about the program are easy fixes and aren’t worth going into details (clarify website message, advance notification of the process & dates, facilities, etc). In general, a few small things could be improved, but the Lead To Win program is built around continuous improvement so these kinks will be worked out with each new session.

I have only good things to say about the concept, the presenters, the quality of the presentations and how good you need to be to get through the filters. The latter was something I was especially worried about, because weak filters would undermine the whole credibility of the program. You don’t need to be a superstar to get through, but I was surprised by some of the talented individuals who did get filtered.

I was also happy to see that most of the program was not tailored for people with dreams of VC funding. They burst that bubble fairly quickly. The program pushes you to reach an appropriate scale but I enjoyed how the focus was on growing your business and not about reaching 100 million in revenue in three years. This is a big thing to me because I like to avoid crowds of dreamers that don’t get anything done.

Conclusion

If you’re serious about starting up a high-tech business in the Ottawa/Gatineau region, consider Lead To Win.



Lambda IEqualityComparer<T>

clock May 5, 2010 16:16 by author EtienneT

Just show me the code.

You’ve probably used an IEqualityComparer<T> before.  If you have, you probably know that using one is a pain because you need to implement the interface in your own class and override your Equals and GetHashCode methods.  In this post, we’ll focus on the most common scenario for checking equality: primary key comparisons.  For example, the CustomerID property of a Customer class.  This article offers a simple solution inspired by a StackOverflow post.  We’ll use lambda expressions instead of subclassing IEqualityComparer<T> for each class, thus eliminating lots of code and making everything far more readable.

A simple example should clarify the situation.  Here’s the traditional way you’d use an IEqualityComparer<T> to compare two Customer objects.

First extend from IEqualityComparer<T>:

public class CustomerComparer : IEqualityComparer<Customer>
{
    public bool Equals(Customer x, Customer y)
    {
        return x.CustomerID == y.CustomerID;
    }
 
    public int GetHashCode(Customer obj)
    {
        return obj.CustomerID.GetHashCode();
    }
}

Then you would use this new CustomerComparer class like so:

// First parameter == CustomerID
var x = new Customer(1);
var y = new Customer(2);
 
var list = new List<Customer>()
{
    new Customer(1),
    new Customer(2)
};
 
list.Contains(new Customer(1), new CustomerComparer());

As you can see, quite a bit of code just to find an object in a collection. (In this example, if we had not used our CustomerComparer, we would not have been able to find this new instance of the same customer in our list.)  Most of the time, the comparisons we want to make are pretty simple and could be expressed using a single line of code. Allow me to introduce my class (strongly inspired from this StackOverflow post) before showing a code example. This class allows us to pass a simple lambda expression to construct an IEqualityComparer<T> on the fly:

public class KeyEqualityComparer<T> : IEqualityComparer<T>
{
    private readonly Func<T, T, bool> comparer;
    private readonly Func<T, object> keyExtractor;
 
    // Allows us to simply specify the key to compare with: y => y.CustomerID
    public KeyEqualityComparer(Func<T, object> keyExtractor) : this(keyExtractor, null) { }
    // Allows us to tell if two objects are equal: (x, y) => y.CustomerID == x.CustomerID
    public KeyEqualityComparer(Func<T, T, bool> comparer) : this(null, comparer) { }
 
    public KeyEqualityComparer(Func<T, object> keyExtractor, Func<T, T, bool> comparer)
    {
        this.keyExtractor = keyExtractor;
        this.comparer = comparer;
    }
 
    public bool Equals(T x, T y)
    {
        if (comparer != null)
            return comparer(x, y);
        else
        {
            var valX = keyExtractor(x);
            if (valX is IEnumerable<object>) // The special case where we pass a list of keys
                return ((IEnumerable<object>)valX).SequenceEqual((IEnumerable<object>)keyExtractor(y));
 
            return valX.Equals(keyExtractor(y));
        }
    }
 
    public int GetHashCode(T obj)
    {
        if (keyExtractor == null)
            return obj.ToString().ToLower().GetHashCode();
        else
        {
            var val = keyExtractor(obj);
            if (val is IEnumerable<object>) // The special case where we pass a list of keys
                return (int)((IEnumerable<object>)val).Aggregate((x, y) => x.GetHashCode() ^ y.GetHashCode());
 
            return val.GetHashCode();
        }
    }
}

Here is how you would use this code:

var x = new Customer(1);
var y = new Customer(2);
 
var list = new List<Customer>()
{
    new Customer(1),
    new Customer(2)
};
 
list.Contains(new Customer(1), z => z.CustomerID);

To be able to use this in Contains<T>, we need to add a new extension method (which was not included in the original StackOverflow post):

public static bool Contains<T>(this IEnumerable<T> list, T item, Func<T, object> keyExtractor)
{
    return list.Contains(item, new KeyEqualityComparer<T>(keyExtractor));
}

Once you’ve done this work for Contains, it is very easy to create extensions methods for Distinct, Except, Union, etc. Furthermore, the same principles also apply to IComparer<T>.

For a complete source code with all the classes and extension methods, you can go here: http://gist.github.com/391397

You can modify this code by forking the gist; don’t be shy to add useful methods!



Collaboratively Defined Business Strategy

clock March 31, 2010 13:54 by author JKealey

 

bookingblast For those of you who’ve been keeping track, we launched LavaBlast Software back in April 2007. A year later, we posted three software startup lessons about how we got started and followed up the year after that with four more fun software startup lessons. Now that Year 3 is complete, I should write another set of software startup lessons, but that can wait. Today, I feel we’ve come full circle because we’ve begun working on the type of fun project that we would have enjoyed doing three years ago, but couldn’t afford the risk. In a sense, it feels like a full circle and a new beginning for LavaBlast even though we’re simply working on a new product.

BookingBlast is going to be legen – wait for it – dary. Read on to know more!

Starting from scratch

Pretty much straight out of university, we started LavaBlast Software. We had no money so we had to be creative. By creative, I mean we had to be cheap, work hard and work on something low risk to pay the bills.  The recipe for success is simple and we’ve said it before. Let’s just say we sell to businesses and we keep the intellectual property. This strategy has allowed us to start from scratch and making a living. 

We already have BookingBlast’s building blocks and now have enough runway to execute on our idea.

Ramping up

Some may stop here – but that’s not enough for us. We have greater ambitions - we’re looking for something bigger - for a greater reward. Based on the assumption that it takes a decade to launch a successful business, we’re not even a third through. We’ve passed through survival and have been growing steadily, but we’re now anxious to move to the next level.

We feel we can get there by converting the enterprise-level software we’ve been producing to date into more scalable Software as a Service (SaaS) products. We’ve been wanting to do this since day 1, but needed short-term revenues.  We’re now re-investing into LavaBlast to give us this flexibility. (I guess that visit to an unspoiled private tropical island will have to wait.)  We toyed with a few concepts during the past year, looking for software products that:

  1. No per-client customizations (greater scalability)
  2. Sold to businesses, not individuals (faster revenue)
  3. Shorter sales cycle, lower recurring dollar amount per sale (easier to commercialize)
  4. Related to our existing work and/or future strategies (reuse and upsell synergies)

 

Hold your horses! I’ll describe BookingBlast’s awesomeness in a minute.

Context & Goal

Our short-term goal with this project is knowledge. We’ve been building enterprise software for a while and want to dumb things down and start aiming for higher volume, but we need to adapt our know-how. We see BookingBlast as a practice run whereas our business is a marathon.

Our long-term goal is growth, in terms of revenue and the size of the company.  Lots of the enterprise-level work we’ve done can be commercialized to a broader market but we need a longer runway.

Spill the beans already! What’s BookingBlast?

BookingBlast allows service-based businesses to accept online bookings. Reservations are accepted only during available time slots and deposits are paid online, in advance.

To clarify, our software will allow customers to:

  • Book your child’s birthday party online
  • Book mobile clowns/magicians/comedians online
  • Reserve a massage / spa services online
  • Book your chiropractor from their website
  • Book a photographer from their Facebook page
  • … and accept bookings/reservations in many other industries.

That’s it. It’s not rocket science. It’s been done already – there are many competitors in this space – the market exists. The barrier to entry is low. But that’s not stopping us, because we have a plan. What better way to test our plan than to go out and execute it?  The worst that will happen is sales will be lower than desired and we’ll still reach our short-term goal of knowledge. We’re not betting the farm on this – it’s a stepping stone in the context of our longer-term vision.

How did you come up with your secret master plan?

We understand that this is a marketing play more than a technical one. We’re not inventing a killer product, although we can be innovative in our implementation. We decided it was in our best interests to share our plans for BookingBlast with people from diverse backgrounds and get them involved in the process. Ian Graham of The Code Factory always says the engineering students/graduates from the University of Ottawa are more secretive than the ones from Carleton University and we decided to prove him wrong. We openly solicited feedback on Google Wave and at TeamCamp. In the end, we found that we’re not that crazy after all as this validated our initial opinions. We did discover a few interesting twists which we plan on using, however.

Therefore, our plan is not secret – you’ll hear more about it when our product will be in beta. However, here a few lessons we learned from our experiences with collaborative planning.

Phase 1: Internal research

We looked around to find competitors and market penetration strategies. We discussed this internally over a coffee and did our homework. I produced a one-page executive summary of my initial plans.

Phase 2: Feedback solicitation via Google Wave

We published a private wave and invited two dozen random people. We made sure to invite people who were not extremely close to us because their feedback would be biased. We made it clear that the participants could feel free to ignore us as we didn’t care to force anyone into open collaboration, especially if they were busy with their own work. We found that the people least close to us were the ones who contributed the most to the discussion. Within 24h, the discussion had grown to approximately 8 times as long as the original executive summary. Within the next 48h, the discussion grew a bit more, with a few late-comers giving their comments.

The early discussions were the most valuable. They brought in new elements and got everyone involved. They definitely changed our strategy. However, as the discussion grew, I felt that most people lost interest because there was too much to be read. The barrier to entry had been raised, which caused most of the late-comers to elect not to participate. Initially, we thought this was a bad thing as we wanted more feedback, but in retrospect, we feel that what needed to be said was said early on. Had we discussed the same material with each person individually, we would have elicited the same comments over and over. Redundant feedback is not useful (other than for validation) and is a huge time waster.

In conclusion, open collaboration is a great technique to elicit feedback very quickly. I am greatly thankful to those who participated.

Phase 3: Feedback solicitation via TeamCamp

jkjp Ottawa’s primary co-working location, The Code Factory, hosts a bi-monthly event initiated by Chris Schmitt called TeamCamp. Once in a while, TeamCamp will have a pitch night where the participants pitch their idea to the group and get feedback. This is a very informal round-table setup but you get to chat with interesting people in Ottawa. A few weeks ago, I pitched BookingBlast to the group. This was great validation for our online booking software, as it proved that we had properly thought it out. Some new strategies were put on the table, but the biggest lesson learned is that you don’t need to spend months thinking about your project if you’re agile enough to adapt it along the way.

Furthermore, we finally had someone stand up and say our idea wasn’t good enough, something we had been waiting for since we started planning BookingBlast. Given the small scale of the project and the low barrier to entry, I was expecting most people to shoot our idea down quickly. Maybe I watch Dragon’s Den too much and read too many angel investor/venture capitalist blogs. In any case, this brought forth great discussions where it appeared other individuals were reading my mind while defending our online reservation software for me.

We’re now ready to start implementing the project! (In fact, we’ve already started and it is progressing nicely!) 

We need your help

We’ve posted a basic information request page on our website. If you know business owners that would be interested in participating in our alpha/beta programs, please have them sign-up to our newsletter.  We’re approaching the market in a different fashion that what the competition is doing, so we’d love to talk to business owners directly.

Since a good portion of our readers builds software for other businesses, we’d also like to talk to web developers that manage business websites.

Also, feel free to share your thoughts on BookingBlast and how to make it work in the comments. We’re thinking of openly blogging about thinks like SaaS pricing and gathering data concerning some of our strategies for future discussions and commentary.



jUCMNav Tutorial 5: Dynamic Stubs

clock February 21, 2010 07:40 by author JKealey

 

This is the last jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Creating dynamic stubs
  • Dynamically selecting which plug-in map will be selected by a scenario

Links



jUCMNav Tutorial 4: Waiting places and timers

clock February 19, 2010 00:39 by author JKealey

 

This is the fourth jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Introduce waiting places, timers, timeout paths
  • Introduce start point pre-conditions
  • Create a scenario with multiple start points
  • Create a path that triggers a blocked path

Links



jUCMNav Tutorial 3: Loop and scenario enhancements

clock February 18, 2010 00:38 by author JKealey

 

This is the third jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Including a scenario definition inside another
  • Creating an Integer variable 
  • Writing pseudo-code inside responsibilities
  • Creating a loop

Links



jUCMNav Tutorial 2: Adding forks & joins

clock February 17, 2010 07:37 by author JKealey

 

This is the second jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • Creating an or-fork and or-join to model an exclusive choice
  • Creating an and-fork and and-join to model concurrency
  • Merging a start point and an end point
  • Creating a Boolean variable
  • Initializing variables inside a scenario

Links



jUCMNav Tutorial 1: Creating a simple path

clock February 16, 2010 07:46 by author JKealey

 

This is the first jUCMNav tutorial in a series of five. Below are links to other articles in this series.

 

The above video models a simple process for a paintball location. Customers sign a waiver (limitation of liability), pay, and have fun. 

  • How to create a blank Use Case Map
  • Using the Path Tool to create a path
  • Presents the following path nodes: Start Point, End Point, Empty Point, Responsibility, and Static Stub.
  • Presents the “Refactor into Stub” menu option
  • Presents Components and how to change their fill color.
  • Explains how to bind path nodes to components.
  • Create a simple scenario

Links



Software engineers as salespeople

clock February 15, 2010 10:12 by author JKealey

LavaBlast is a small startup; we don’t currently have dedicated salespeople. I still do most of the selling at this point – I’ve got a background in software engineering, not sales. That may seem crazy until you realize that we don’t sell commercial-off-the-shelf software. If a prospect needs us to build custom software on top of our existing platform, the engineering team is involved in determining the scope (and therefore the cost presented in the quote). Because of the scope of the systems that we’re building, we have the “luxury” to spend more time on each individual quote and learning more about the prospect’s business. Adding a personalized touch in every quote gives us a competitive advantage compared to firms that pump out boilerplate text without analyzing the context.  I strongly feel that, for this type of sale, understanding the customer’s problems is much more important than having them understand your product. Furthermore, understanding/solving problems is definitely something software developers know how to do!

LavaBlast Software builds integrated software solutions for the franchise industry. Although the systems we build are similar because we reuse the building blocks which we’ve developed over the years, we understand that each franchise has different business rules. Understanding these rules before building custom software is of capital importance. This assertion holds regardless of what kind of software you’re building: everyone on the team should have a clear understanding of what needs to be built. Otherwise, you build software that only partially matches your user’s expectations and you need to go back to the drawing board to correct it.

Don’t get us wrong; we’re not fans of the Big Design Up Front (BDUF) approaches such as the waterfall software development model. We follow a more agile development methodology but there is one thing we do with each and every new franchisor client that approaches us: we model their business processes using a visual notation called the Use Case Map notation, a subset of the User Requirements Notation. This helps us understand their business and what they need built. We’ll come back to this notation in a minute.

Communicating business processes

Most business processes are simple (and should be), but a few are not as straightforward. Imagine an online store that sells quilts: the customer goes to the online store, chooses a quilt or two, provides payment, and the warehouse ships them. Simple enough? Add a few requirements to make it complex:

  • a customer can put a particular quilt (a unique hand-made design) on hold and provide payment for it within a week
  • customers can visit the warehouse and make purchases directly – it takes 24 hours for the website to be notified of stock changes
  • the store also receives telephone/fax orders
  • a customer can return a quilt for a full refund with 15 days, in person or by mail.
    These few extra requirements make the whole process a bit more complex.  In real life, there are always dozens of these added constraints. Some are very infrequent whereas others cause problems on a daily basis. Some can be solved by a better process while others can only be mitigated (especially things like delayed notifications) – you need to understand the context to be able to represent the current process and differentiate it from what you see as the ideal process to be implemented. However, as you are the developer and not the domain expert, you need to effectively communicate with the other stakeholders in order to create the best system. In most cases, your best guess is not sufficient.
    We’ve found that the best way to communicate these processes with our customers, who are not in the software world, is by using the User Requirements Notation. The notation provides a way to visually represent processes very quickly. Spending a few minutes designing a Use Case Map is akin to drawing on a whiteboard, with the added benefit of being a persisted artefact that can be “executed” to visualize certain scenarios. Additionally, the Goal-Oriented Requirements Language (the other half of the User Requirements Notation) allows the designer to compare different processes in terms of non-functional requirements such as performance, maintainability, security, etc.

Better than drawing on a whiteboard

Back in 2007, we’ve talked about the Use Case Map notation and jUCMNav in our initial blog post. To celebrate the release of jUCMNav version 4.2.0, we thought it would be nice to produce a series of tutorials that show you how to create your own model using jUCMNav. In case you didn’t know, LavaBlast’s co-founders have contributed massively to jUCMNav in the past five years. We’re responsible for 60% of the code in this open source project which we started during our time as undergraduate software engineering students at the University of Ottawa.

The following is a short 90 second video that gives you an example model and a very quick overview of what can be done with the notation and the tool. Stay tuned to our next blog posts to see us build this example from the ground up. The overview and the tutorial are intended for people with a background in software development. If you wish to introduce the notation to someone outside the development community, I would recommend starting with simple screenshots instead of showing the tool (which, in the end, should only be used by developers).

Conclusion

We hope you found this introduction interesting and that you’ll not only watch our upcoming tutorials but also download jUCMNav (an Eclipse plug-in) and play with it!



Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017

Sign in