"Is Meteor" / "Are the MDG" <insert negative connotation here>

[sergiotapia]

Don’t get tied up writing abstractions for things you might need. How often do you see yourself switching view layer technology? How about switching something as fundamental as the database?

Food for thought: http://www.joelonsoftware.com/articles/fog0000000018.html

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all.

[sergiotapia]

MDG’s business is building developer tools. Are you building developer tools?

[sergiotapia]

Then rest easy knowing your boss won’t ask you to switch to webpackigulpjsRxFlow. You can safely assume fundamental parts of your stack won’t change. Spend your limited time elsewhere and build value for your company instead of conjuring endless shoulda coulda woulda scenarios.

[khamoud]

Well MDG has done it at least 3 times now

I can only count 1. Blaze -> React. What was the second and third? I mean if you include them changing away from Spark wayyyy back but that had such minimal effects on anything that I wouldn’t count it because it was still fundamentally handlebars.

So having to change from

Template.myTemplate.onCreated = function(){}

to

Template.myTemplate.onCreated(function(){});

Didn’t bother me too much. At the worst it was mildly inconvenient.

[sam]

Great points being posted here, and totally understand the concerns - let’s separate those too

When I talk about separation of concerns, I don’t mean the separation of HTML/JS. Those may well be combined into something like JSX to take care of a specific concern. This isn’t the first time this has happened, Java has JSP's and .net has ASPX files that mix HTML and code. I also don’t mean separation of client / server, or pub / subs.

I’m referring to:

• Business logic concerns - the rules within the business domain
• Application concerns - ensures the business logic has what it needs to
• Presentation concerns - how do users see and interact with the application
• Persistence concerns - how data is retrieved and stored
• Framework concerns - this is where Meteor comes in and gives you all the wiring you need to achieve much of the above

You basically create interfaces between these layers to talk to each other, and you end up with maintainable (and highly testable) code.

Forgive me if I’m wrong, but from reading your comments above and in other threads @aadams, I suspect you’re not deeply familiar with some of these concepts. And also from your comment @sergiotapia I suspect you are familiar, but don’t know where to draw the line when it comes to abstraction. Therefore I highly recommend reading this fantastic article about Hexagonal Architecture that should really clarify the concepts I’m trying to put forward here.

The community is certainly here to help everyone with everything. If you need help migrating, or knowing how to separate concerns, ask away and expect help.

My original post is not about altruism, or about right vs wrong, it’s about what I believe is needed to survive the ever-going change in technology and to avoid disappointment, and that is a combination of continuous learning and building flexibility within.

[aadams]

Thank you for the clarification @sam. I do understand what you mean, in .NET we had abstractions at every level with Repository, Service, and Unit of Work patterns, class factories, separation of concerns, aspect oriented programming with proxies, n-Th tier architectures with WCF Restful webs services.

I know that abstractions such as these help isolate us from change, but only if the interfaces don’t change much; I think more that a little interface change is coming to Meteor in the next year.

I also think that the separation of concerns offered by Blaze is a true separation, maybe not one you think matters much but one none the less, that could have helped with one type of transition – it just turns out the transition was so fundamental that probably no amount of abstraction could have helped.

MDG isolated us from having to deal with stuff like domain/architectural level abstractions. This was a good thing if you needed to get a product into production quickly, but it turns out that was a bad idea now that a whole sale tech change is taking place.

But here again, I think no amount of abstraction could possibly insulated us completely from a situation in which there is no more: Tracker, Blaze, Mini-Mongo, MongoDB. And instead we have an abstraction like GraphQL, some transport layer, and React. This is the transition that is taking place as we speak.

That’s not to say that after the transition to React + Facebook stack, and with sufficient abstractions, these types of transitions won’t go smoother – I think they will as long as the tech change is not something completely different.

Your title and opening line seemed to me to imply a negative cogitation towards some that have posted “Is Meteor” threads. Yes it’s because the tech is changing to an extent, but I think also it’s due to a lack of information from MDG as to the direction and degree of change coming our way.

And yes, I take exception to some who seem to poo poo others that don’t take the partly line or ask questions that might make some uncomfortable. Having said this, I think posts that are insincere and just for attention are a negative to the Meteor Community and reflect poorly on the poster.

Yes, I will eventually need help migrating. Hopefully the Meteor Development guide and Mantra will help.

[vonwao]

Testing is not really an idea, it’s a practice. There are many ideas behind the practice. Just like Yoga

Well that explains it, I find Yoga equally as useless

I’ve seen hundreds of different unit testing frameworks in my life and I’ve hardly seen anyone write a useful unit test, except if one is creating a library that needs to ensure backward compatibility.

For application code, it’s a complete waste of time. Especially when one starts creating mock objects and abstracting the data layer. One will spend all their time fixing their tests anytime anything changes. And of course then one won’t want to refactor anything because who wants to go through that hassle.

Testing in my opinion is a fundamental part of writing adaptable code. When you have a large team + a large codebase, you won’t move very fast without testing.

Large teams are nightmare in any case. And writing tests doesn’t prevent from writing bad code, does it?

[sam]

Haha, that’s hilarious about Yoga, don’t tell my wife that she’s a Yoga instructor

Using mock objects to shut dependencies up is a direct result of not applying the correct separation of concerns between your layers. When you isolate the domain from the persistence and focus only on the logic, then the tests tell you when the logic broke and not when your wiring broke. This is the biggest pain that developers that don’t know to test properly.

This is an education problem about testing not one of testing itself. And so back to my original point:

it’s harder to read a ton of information, apply it, and become a better developer. That stuff takes investing time and mental energy.

You don’t have to learn about or do testing if you don’t want to, but I think you should rethink your logic as there are endless books, articles about proper testing, and there are countless great companies that employ testing as to delivery high quality at scale.

In my experience, larger teams can indeed be a nightmare, and they can also move mountains. Depends on the leadership and the attitude of the team.

[sergiotapia]

I used to find testing useless as well, but experience is a harsh teacher.

How do you onboard new developers to your project? Back in the day we made changes, ran app, manually tested, rinse and repeat a gigantic waste of time. Especially on BlackBerry (shudder) where you had to build, compile, then deploy to the mobile device using their ugly software, wait 3 minutes for the device to restart, then run your app.

Those were dark times. (2007)

[jacobin]

This is an education problem about testing not one of testing itself. And so back to my original point:

Separation of concern is a separate concern to what is really being discussed in this thread. It’s generally referred to in OO as coding to interface. That is where the contract is critical but the implementation is totally opaque. The work up front saves you bucket loads of time over the long run. You are then able to rewrite or refactor entire pieces of your application and things that depend upon it don’t even notice.

In terms of testing, the person who writes the code should never be the one who actually tests it. They invariably always test for positive. Once it’s in the wild the users tend to do something altogether different!

[sam]

@jacobin

In terms of testing, the person who writes the code should never be the one who actually tests it. They invariably always test for positive. Once it’s in the wild the users tend to do something altogether different!

I have to agree with a couple of points you made, but overall respectfully disagree!

This is yet another area where you are not separating concerns!! It feels like I’m endlessly banging this drum!

Developers always work to a specification. Be that the back of a napkin or something formal like a use case. In both cases, the developed code is considered “done” by some check. That check is often an eye-ball. Automated testing is about replacing the eye-ball check of “done” with a an automated test. This can be a paradigm shift for many people.

You are correct in that both the eye-ball check and the automated-test check are not enough, and you need to also apply another level of non-automated testing checking, which is called exploratory testing.

The combination of automated testing and exploratory testing is what creates the best feedback. The former protects your code long-term and the latter finds bugs. Both of these techniques provide feedback that helps reduce bugs and improve quality, and together they are most effective.

[jacobin]

You are correct in that both the eye-ball check and the automated-test check are not enough, and you need to also apply another level of non-automated testing checking, which is called exploratory testing.

I like that name for it. I always drilled into my testers the mantra of “Try and break it.”

Put numbers into string fields, paste war and peace into it looking for missed overflows. Put letters into that social security field. Spam click the interface buttons.

I found that a good set of testers is essential for reliable software. You can’t just hand them an interface and a testing itinerary. That’s no different in terms of results than a coder testing his own code.

[jamiter]

@jacobin

Put numbers into string fields, paste war and peace into it looking for missed overflows. Put letters into that social security field. Spam click the interface buttons.

If you do this in an automated test (which you can with chimp) then you will know it will work in the future as wel. No need to this manually every time. Automated “Try and brake” Just an idea, but with things like chimp/cucumber/webdriver.io a lot is possible.

Maybe you can even create a random form filler and submit it a 100 times, without it generating errors. Hm, would be kinda cool.

We have a large code base ourselves with more and more developers working on it. The automated tests give us a lot more confidence that the logic (unit tests) and interface (end-to-end) tests are still working correctly.

@vonwao

For application code, it’s a complete waste of time.

Well, nope. It helps us to write testable code (because you have to automatically test it), which make you think how you write your components/modules. This is something you always have to do of course, but now you have no choice. We can also refactor faster because the tests will tell us if we broke anything. It has been a great experience.

Clicking through your application to see if everything still works, thats a waste of time. Automate it. Unless clicking randomly. Automate that as well

The real issue with testing from my point of view is that the setup used to suck and take a lot of time. But using chimp and jasmine in packages it is getting a lot easier. Once you have your cucumber steps set up, writing a form test is easy. You will no longer wish to it by hand…

[jacobin]

If you do this in an automated test (which you can with chimp) then you will know it will work in the future as wel. No need to this manually every time. Automated “Try and brake” Just an idea, but with things like chimp/cucumber/webdriver.io a lot is possible.

Sorry but you just cannot do that. The examples I gave were not meant as an explicit list, but an implicit generalization.

Nothing automated can replace the sheer idiocy or downright maliciousness of a human being. They are very creative. Especially hardcore gamers. I’ve found over the years they make the best testers and tend to find holes you never dreamt of.

You want human testers not following a script. Like @sam said you want exploratory testing. By that, we mean an invasive colonoscopy.

[Sanjo]

I agree with you because those tests aren’t random at all. It’s thinking about relevant edge cases and making sure that the application handles them appropriately. You can achieve that also with Test-driven development and Specification by Example (aka BDD).

[jamiter]

I agree that a computer test can’t replace a hacker and most tests aren’t random. Most of them are about specific (edge) cases. That’s nothing compared to someone trying find exploits in your system. So we will still have to have a person testing. But most of the “standard” actions in your system and at least all happy paths can be tested. Not for security, but for keeping your support tickets low So for me the conclusion is: you need both.

What I was suggesting in the other comment was more of a question: Aren’t there ways to automate “hacking”, or at least bad input being entered? The random form filler was a suggestion. You do have tools that randomly click on the screen until an error occurs. Which is fun to look at, but maybe not so useful.

@jacobin

Nothing automated can replace the sheer idiocy or downright maliciousness of a human being.

There’s a lot of truth in that

Anyway, maybe getting to much of topic here.

[vonwao]

I see so many dumb things in software, from poor usability to ugly code… and unit testing doesn’t make much of a difference.

[sam]

Haha, that’s funny. I think I’ll use that image in my next chapter! Here’s another one just like it:

Both of these animated gifs are alluding to the same context, that unit tests alone are not enough. I’ve discussed this here. This is exactly where you need integration tests, to make sure units work together. Not just any integration tests however, but ones that integrate well-designed, decoupled units of code.

Every single instance where I hear " testing doesn’t work", it always comes back to the same underlying reason: a misunderstanding and bad application of testing.

It’s like jumping on a snowboard and saying “it doesn’t work, it’s too slippery!”

If you learn how to snowboard by yourself, you can definitely get by and even get good. If you learn from friends, you’ll be better, but if you put in the effort to learn from professionals through reading books, watching videos and training, you will spot your errors, learn best practices, and up your game. The exact same principle applies to testing (and many things in life actually!), which is to:

Keep evolving