Accelerating Meteor Mastery

[GaryBartlett]

Hi Folks,

TL;DR

1. I specialise in accelerating individual and collective mastery.
2. I would like to collaborate - part-time - in the application of my thinking technology to learning and mastering Meteor.
3. What we create will support rather than replace what’s already out there.
4. Reply (on- or off-forum) to indicate your interest in (a) Building the content or (b) Using the content to learn Meteor.

The Basic Idea

I’m just beginning my Meteor journey and would like to explore the interest in and merits of collaborating in the building of a simple framework for learning Meteor more quickly and easily. The intention isn’t to replace what’s out there already, but to enhance and support it.

I’ve browsed the various free resources available - and bought a couple of commercial ones. I applaud the effort and dedication taken to build such high-quality material.

A critical dimension is missing, however, and I would like to contribute that missing dimension, in collaboration with someone or a group of people who already understand Meteor at a deep level (and ideally, have built or are building training material of some sort) and are looking for a way to accelerate learning and enhance the impact of the material they’ve built.

What I have to Contribute

I’m not a full-time developer, but have developed .NET, PHP and VBA apps over the years: some for clients and some for internal use.

I’m a dramatic improvement specialist, consulting to senior execs in global and national brand companies. I work in the intersection between system science (leverage points in complex systems) and cognitive science (leverage points in individual and collective behaviour).

My time is spent (a) developing counter-intuitive dramatic improvement solutions and (b) helping execs and departments create a compellingly attractive virtuous-cycle pull-system for change that people embrace with a passion - to replace the conventional and dreaded vicious-cycle push-system for change that people can’t help but resist with a vengeance.

I’m learning Meteor in order to prototype a set of SPAs for disseminating these dramatic improvement frameworks via a SAAS platform.

Deliberate Mastery

The technique I want to apply to learning Meteor is called Deliberate Mastery. It’s a cognitive framework for deliberately and systematically accelerating capability - virtually at first and then natively. The first framework will target Meteor novices who have a basic understanding of traditional js - because that’s where I am at present. Subsequent frameworks will take people deeper - and extend backwards, possibly even to beginner developers.

The first layer of Deliberate Mastery, as far as accelerating learning Meteor is concerned, is to create the cognitive operating framework first (with minimal conceptual support) and only then illustrate with examples and support with concept in the conventional way. The “cognitive operating framework” is what is missing in conventional approaches. As a result, this framework gets built as a result of doing and so learning, rather than enabling and accelerating the learning and doing.

Simply: If people understand, in simple terms that they already understand, how things work together, the specific step-by-step instructions actually make sense in real-time, rather than only at some point in the future, in retrospect.

There are other layers to Deliberate Mastery - no need to cover them at this point.

Expected Outcomes

I expect that the collection of cognitive frameworks that we build will be open source and that nearly every Meteor training material producer will adapt them for his/her own particular style and target market.

More people (including me!) will learn Meteor faster and more easily. There will be more more useful contributions to the community over time. Meteor will evolve faster, as a result.

Your Response

Please indicate your interest (on- or off-forum) in either:

1. Collaborating to build the frameworks or
2. Using the frameworks to accelerate learning Meteor yourself.

Thanks very much.

Gary Bartlett

gary dot bartlett at prodsol dot com

[a.com]

Will there be any demand to be an expert in meteor 3 years from now?

Seems MDG = Apollo + build system + galaxy

and may end up leaving DPP + Blaze + etc. to the wayside unless it’s given to an open source community. It seems there are enough people who like old meter + blaze to keep it alive.

[trajano]

I prefer to think that Apollo will obsolete DDP. The UI would be either Angular 2 or ReactJS depending on the enterprise and whether Angular 2 can get the traction considering the amount of dependencies it relies on and does not really control. Finally we’d have a common deployment plan to deploy Meteor into the enterprise with Meteor 1.4+ when the version Node is no longer a enterprise deployment issue.

[ramez]

Agreed that Apollo (i.e. data layer – DDP v2) seems to be where MDG is headed as data is the root of all apps. I also have the feeling the community will eventually take care of all view layers (regardless of technology used). MDG is bootstrapping it for us (thanks!)

Blaze has its ecosystem - which was born here and will become community-driven.
The other ones can be built on external dependencies (e.g. React and FB ecosystem – Angular / community – Vue – ViewModel etc.). Eventually MDG will have to let React / Angular go too and they are left to the community to manage them.

So Meteor would be: View layer of choice + Apollo + builder

If Apollo does not pick up (and generate money soon), then I expect the Blaze community will take over the builder, and the other view layers (mainly React and Angular) go back to their roots. While this is in itself a sad thing with all the contribution MDG has brought to the table, the mere fact that there is a community willing to jump in, makes it low-risk and increases adoption rate.

Back to the OP, as loing as we agree the path forward is uncharted, but we have some direction. I believe it’s very much worth the effort.

@GaryBartlett, thinking how I can contribute will post back.

[ramez]

@GaryBartlett,

I havent 't personally paid the $99 as I don’t pedagogically subscribe to the way it is presented, but this resource has great reviews:

https://bulletproofmeteor.com/

How does it fit with what you have in mind? It’s hands on and covers things step by step (albeit, a bit dated).

[maxhodges]

perhaps you should focus you value-driven deliberate mastery on a Meteor SPA which initiates pretentious jargon reduction. By repurposing your pull-systems and cognitive frameworks you could leverage synergies and build mindshare with change agents by incentivizing them to decrease corporate consultant fatuity.

Mission-critical consultingese reduction robust SPA SaaS platform parser output

OFFENDING WORD – Ecosystem SUGGESTION – System COMMENT – Frogs, bugs, fungi and so on. If you’re not writing for National Geographic, you’re probably not writing about an ecosystem. A dated term to be avoided. Moderate bull foul. If you’re writing for National Geographic, we apologize. We enjoy the pictures. OFFENDING WORD – Extensible SUGGESTION – None COMMENT – You don’t really know what this means, we don’t really either.

Here’s a pull-request to bootstrap your package.ini

{
"push-system": false,
"pull-system": true,
"pontificate": "a lot",
"imports": {
  "cognitiveOperatingFrameworks": "v0.01",
  "thinkingTechnology": "v1.01"
},
"lessons": [
  {
    "title": "How to sound smart",
    "content": "Use big words no one understands."
  },
  {
    "title": "How to sound smarter",
    "content": "Take big ideas and explain them with words everyone understands."
  }
]
}

[maxhodges]

Joking aside. There really isn’t a single specific set of steps to dramatically improve the rate at which anyone could learn Meteor. Each person comes with their own background and unique set of skills, experiences and abilities. Some have a lot of experience with similar node.js frameworks and No-SQL databases. Others have familiarity with less related technologies, like PHP, ROR, .NET and MS-SQL. Some are expert front-end designers, while others know only bits and bobs of HTML and CSS.

Learning to develop with Meteor isn’t simply a matter of mastering a series of concepts unique to Meteor. It also demands knowledge of things like HTML character entities, CSS selectors, JavaScript scope, callback function patterns, responsive grids, state machines, map/reduce and other Underscore functions, JQuery, JSON syntax, Mongodb queries, troubleshooting, and all kinds of ideas about how servers and browsers work.

So the challenge with creating any kind of general instructional material is that there are huge variations and gaps in people’s experience with and understanding of the broad range of technologies involved in creating Meteor web applications. Assume people know too much, and you risk alienating people who are just starting out. Assume people know too little, and you risk alienating people who find the material tedious.

Besides what are your real goals here? Are you simply trying to learn Meteor, or do you really want to create some kind of Meteor training content? If you’re really just trying to learn Meteor, I think there are other demo applications you can build which aren’t going to bog you down so much. Planning, writing, and organizing useful Meteor tutorial content is going to really slow down your progress.

When first started to learn ASP years ago, first I made a multi-threaded discussion forum. After that I built a flickr-like web application for photo sharing (many years before flickr was created!) I’d recommend trying to build something like that as an educational project. Don’t worry about the contents of your demo app, just get the features implemented. Build a site for people to list their rental properties, or create an auction site if you want a challenge.

[hexatonic]

Perhaps the Guide could be improved for people coming from radically different backgrounds. Would it be fair to say the authors of the guide:

1. Assume newbies want to build a somewhat naive application from a data perspective.
2. Assume we care more about sexy UI features than we do about data.
3. Assume it’s OK for testing to be second class citizen.
4. Assume it’s OK for debugging to be a third class citizen.
5. Assume that newbies will accept lack of support for SQL and/or ORMs.

My intro to Meteor has been a bit painful so far, partially because I’m not sure what learning sources I should use, if they are outdated, and what packages I should use, and why they are not core when their use cases seem so trivial. For example, why do I need to decide between competing third party packages to do something as common as many to many relationships? Shouldn’t this be cooked in? )

So far, trying to build a very simple app has been met with an array of dead ends. So yes, I like the idea of newbies from other frameworks working together to overcome some of these “common” obstacles.

Many people on the forums have been very helpful, but this is a slow way to learn. The Guide must be the canonical source IMO.

[shilman]

I learned with Discover Meteor. I don’t know whether it’s up to date with all the recent changes in Meteor (I’d be surprised if it was!), but back at around the Meteor 1.0 release when I read it, I found it to be super well-written and clearly-explained.

I think the Discover Meteor format is really great: walking you through building a specific app (in their case “Microscope” a simplified Reddit clone), while explaining Meteor concepts along the way. It’s a sweet spot in between a Tutorial, which is shallow, and the Guide, which is more of an encyclopedia of concepts and best practices.

Not sure whether such a resource exists for 1.3 Meteor, but if I was starting now that’s what I would want. @sacha do you have any thoughts?

[pal]

SG posted a very useful and characteristically generous blog post with a Study Plan for Meteor 1.3 over at DM

You made me nostalgic for the old days with your comments about DM. Salad days!
MDG and Sacha made me love web-dev in a way i hadn’t since dynamic drive/dhtml

But of course, its only perception that we have to move on (for now anyway). Blaze is still brilliant for getting something out, while for future proofing Apollo should become one’s focus as said above, regardless of frontend

[Spyridon]

Honestly I feel 1.3 came with a much higher learning curve than earlier iterations.

The tutorial is much more difficult to follow (even for an experienced user). The new project folders/format completely changed the common organization of projects. Import statements added an extra layer of complexity. And strangely, even the old code in Discover Meteor should work, but there’s no way for new users to know that from the tutorial. The backwards compatibility is not listed on the Meteor site (I had to learn of it through the forums). And relative to the old tutorial, the old tutorial mostly showed you the “Meteor Magic”. The new tutorial doesn’t focus on that magic nearly as much, and puts much more emphasis on “best practices” - when the last tutorial stuck to mostly basics & didn’t even really go in to folder organization much (that used to be learned mostly through Discover Meteor).

In my opinion, 1.3 made Meteor’s documentation appeal more to “serious” developers, but at the cost of comfort for new users. Especially these days when things like view layers (and soon database choices) are options that you have to figure out how to use alongside Meteor.

I still stand by the discussion we had in those topics that came out at 1.3’s release: There should be more than 1 tutorial, and the first tutorial should focus more on Meteor for new users, and best practices as well as the technicalities should be covered on other tutorials and/or the Meteor Guide.

I do think DiscoverMeteor needs a very big update. Updates seemed to cease around when React came in the picture and things went up in the air. It’s probably much harder in the current state of Meteor, as the tutorial would have to focus on multiple view layers, or choose only 1 - and @sacha has been an avid supported of React in Meteor. But I’m not sure if React would be the best choice for a user who is learning Meteor for the first time (which may be the reason for the delay).

[rdagger]

Discover Meteor was my intro to Meteor 7 months ago and it made the transition very smooth.

For me, nothing beats a follow along tutorial for learning a new technology. I’m learning 1.3 with React now and it does require a lot of experimenting to figure out what will work. There is just so much outdated information. Hopefully, Discover Meteor will be updated. I think they would need to make a separate tutorial for each UI.

[Spyridon]

Yep, learning Meteor with React (especially in 1.3) is it’s own project, even if you are already familiar with Meteor.

But to be completely honest, I still think the best way to learn Meteor as a completely new user, would be to use Discover Meteor. Except maybe the Iron Router usage, everything else is up to date.

After completing Discover Meteor, once you understand all the basics (of database access, methods, subscriptions/publishing, etc), then make a project (or update existing one) to learn or upgrade to FlowRouter. This will further make you more comfortable with how Meteor works.

Then you can transition in to the 1.3 way of doing things (the new project organization, import statements, etc).

Only then would I recommend moving on to React, unless you already have prior React experience. The main reason for this is most of the learning information is NOT in React, so you should have a solid grasp on Meteor before you start playing with React.

[sacha]

Well, in an ideal world, Discover Meteor would be updated to follow the structure I outlined in my study plan. But I doubt that will happen for a variety of reasons: it would be a ton of work, basically a complete rewrite. And with so many big changes in Meteor’s near future (move to NPM, Apollo, etc.) it doesn’t seem like the best time to invest so much effort into a rewrite.

Right now the most practical way of learning Meteor in my opinion is to learn React first. Most of your codebase’s code will probably be React code anyway, and it’s also a portable skill if you ever need to use a different stack.

I still think Discover Meteor’s step-by-step, from-the-ground-up approach is the easiest, fastest way to learn, but we might just have to do without it for now…

[hexatonic]

Too bad I paid full price for Discover Meteor recently, only to “discover” shortly thereafter that it was out of date.

My learning path now is to start with React as a standalone framework. Then at least I can use it with Python Flask if I decide Meteor is not the ticket for me on the backend.

[GaryBartlett]

Thanks, @a.com - good question that I didn’t know the answer to. Seems as if there are many similar perspectives in the other comments, so obviously something I need to get my head around.

[GaryBartlett]

Thanks, @trajano: seems like I might be biting off more than I can chew…

[a.com]

It may even be worth holding off and revisiting this idea in 30-60 days. Things are moving so fast, maybe the dust will have settled more by then… rather investing time and effort trying to wrap your head around so many dissenting views (in a situation where only time will tell).

[GaryBartlett]

Thanks, @ramez.

When you say “it’s very much worth the effort”, do you mean that Meteor is very much worth the effort or that building a faster way for beginners to learn Meteor (whatever it turns out to be) is worth the effort? Or both?

If you were at my level, with only part of my time to allocate to learning, would you learn the Meteor ecosystem, or would you learn something else? I could always keep playing with PHP et al and wait until Meteor’s path forward is clearer.

I know that it will take time and effort to learn a new framework of some sort, but had reached the conclusion that that time would be paid back in spades within around 2 months. I have a lot of SPA’s to build and I’m betting that any framework will be worth it in the long run.

'Thought that Meteor would get me up and running fastest, but am now questioning that thought!

Advice?

[GaryBartlett]

Thanks, @ramez - I hadn’t come across this one. It seems quite a bit further down the track than I need right now (focusing on fast and efficient apps, rather than quick and easy human learning). I can see what you mean about the way it’s presented.