All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Node.js tutoring - €150 for 5 hours, €250 for 10 hours (limited availability)
(Somewhat delayed in posting this here, as I had to get posting access to the Offers section first.)
I've been doing code review and tutoring for Node.js for some time now, and it's been a while since the last promo - so here's a new one! It doesn't really get any cheaper than this anywhere 
I'll keep it short; this is what's on offer:
- 5 hours of private tutoring, for €150 (ie. €30/hour), or
- 10 hours of private tutoring, for €250 (ie. €25/hour)
During these hours, I will help you out with whatever Node.js-related topics you want to learn about, no matter what it is or how complex it is - whether it's basic Javascript syntax, building a web application, working with asynchronous code, building distributed systems, writing command-line tools, deploying applications in production, or anything else. There's also not a single teaching method - I will adapt to whatever approach works best for you personally.
This offer is valid until November 13, but purchased hours don't expire, so you can schedule sessions whenever you want. This offer will also only last for 40 hours in total, across all buyers - after that, the normal price of €40 per hour applies. You can purchase any combination of hours within those limits, of course.
The practical bits:
- Your timezone doesn't matter, as I can accommodate most schedules - just make sure to schedule two or three days in advance. Weekdays preferred, but weekends also possible.
- The communication method used during tutoring is IRC or XMPP, whichever you prefer. I can help you setting up either of them, if needed.
- GitHub Gist is used for code sharing, and where necessary, TeamViewer is also an option.
Payment terms: You can pay through Bitcoin, PayPal, or SEPA. All payment is upfront (pre-paid), and to be eligible for this offer, you must complete your purchase before November 13. Payments made for this offer are not refundable, whether in full or in part.
As my automated booking system isn't done yet, you can book through e-mail ([email protected]), XMPP ([email protected]), IRC (joepie91 on Freenode), or through a PM here on LowEndTalk. Keep in mind that my IRC client doesn't always notify me of PMs, so the other methods are usually faster.
If you have any questions about the offer, you're always welcome to ask them - whether in this thread, or privately!
Some honest, unedited reviews from customers (as was requested in a previous offer thread):
Josh Reeter: I reached out to joepie91 through IRC for help on reviewing my code, his confidence, open source contributions and experience within the language I was targetting was a great match for me. His mentorship has really helped improve the quality of my code through consistency and just a better understanding of concepts.
Tejas Manohar: Sven is an incredibly talented developer that works with utmost diligence. He has thorough knowledge of Node.js platform along with the tools built on it and is really passionate about crafting the right implementation to solve most any problem at hand.
Daniel Sauerbrun: I hired Sven (joepie91) to help me beat the learning curve for Node.js; I needed quick tutoring as I was building out a codebase from scratch for a startup. Not only was he an excellent tutor in helping me understand concepts instead of just giving me the answer, but he was also available for me pretty much whenever I needed him. I expected to need ~25 hours of his services; however, I have made so much progress with him that I can't seem to get past 10.
Kaveh Khorram: In about only 8 hours, Sven (joepie91) taught me about modularization, callbacks, working with third-party modules, correct variable use, express routes and promises just to name a few. Sven often went into overtime just to make sure I understood a topic, and always made sure I had a thorough understanding of the material before ending a session. Sven is one of the most, if not the most experienced NodeJS developers I've ever worked with.
Comments
I've heard that you are pretty arrogant and unwilling to listen at times, does this affect your teaching style? Or are you willing to work with a person to hone a developing or strong skill?
Sooo LET has no limits whatsoever on pricing of this kind of bullshit?
I offer dogespeak tutorial for 1500 EUR per hour paid in dogecoin in advance.
I'm in.
And yeah in countries "some of us" live many people earn less than that in a month, so not only you are trying to mis-use LET by exploting a rules loophole for your own personal profit, you are just generally an arrogant little asshole.
After just thirty minutes of rm's private dogespeak lessons I can now express surprise in dogespeak.
10/10 best service I've ever used.
LOL guys
On a serious note, maybe this kind of offers about services should be reviewed by the mods/admins.
Personally I think it's ok to have some of these here.
Okay so if you're one of those people, clearly you shouldn't be using his services... If this is an approved offer, I don't see what the problem is. I don't know how to tell you this, but some people have more money than others... /gasp
I'm not unwilling to listen, just unwilling to give in on a point without a solid argument against it
But yes, I do apply the same during tutoring - it's part of why it's so effective/efficient. I don't unnecessarily lash out, of course; the primary goal is to teach people, and that usually doesn't require arguing.
Should've probably been clearer about that - it doesn't really get cheaper than this with this level of experience, in the fluently-English-speaking world (as far as I have seen, anyway).
This definitely isn't "exploiting a rules loophole" - before I ever posted a thread about this, I explicitly requested permission from staff (and got it approved), and the pricing levels haven't changed since.
This definitely is, because this is not clearly regulated in rules, no price limits set, no clearly lined out requirements to the "provider" (ha-ha) and staff allows or disallows it based on what, only their personal judgement. May be okay only today and only for you, may be not okay for someone else tomorrow.
That doesn't make it a loophole, that just makes it poorly defined (which I agree is the case). The only way to change that, is to bring it up with staff.
May I know what are the selling points as I believe if one wants to learn nodejs they could easily look for guides and documentation online.
Just my 2cents.
Wow, didnt expect that from @rm_ @0xdragon .
Chill out guys
While the existing documentation for Node.js (at least on a basic level) is of varying quality - for example, there aren't really any proper 'getting started' guides, and
learnyounodeis full of outdated and/or inaccurate information - it definitely is possible to learn Node.js without tutoring.If that's your thing, then you should just do that - it's going to be a lot cheaper (most likely even free). I'm actually working on improving this kind of documentation myself - though still very much a work-in-progress, I've put together some references on how to get started just yesterday.
However, sometimes that isn't an option - somebody might learn better when they have somebody teaching them, or they might be working on something strange that no documentation really exists for. That's the kind of thing that I do tutoring for.
You're not so much paying me for my knowledge (I'll gladly share that for free) - rather, you're paying me for my time. A few hours of uninterrupted full attention, and the ability to bounce any question off me, and ask for clarification where needed, tailored to your specific experience with programming (if any). Including how to approach the building of things that don't exist yet, and for which no real examples exist.
Right, cause otherwise how would the first person to figure it out have done it?
Technically speaking, it's possible for Node.js to be impossible to learn without tutoring.
The person who wrote the language would know how to use it because he wrote the language. (if you define "learning" as the "acquisition of knowledge", the creator acquires no knowledge and thus never "learns" Node.js, excluding him from the logical tree of learning node.js) He could teach it to someone else who in turn could tutor someone else and so on. Even if it were impossible to figure out how to do it without tutoring, the language could still exist and this service could still exist.
While I agree with your sentiment, your logic is flawed.
I don't disagree with your definition of learning, but I disagree that the creator of Node.js would acquire no knowledge while creating Node.js.
The creator acquires knowledge not from another person, but through trial and error.
Your view allows the creator to end up "knowing" Node.js without ever having acquired the knowledge.
As a Javascript/Node newbie, I would agree with @joepie91 . The documentation is awful/incomplete/outdated. Part of the reason is that the whole framework is evolving very rapidly - Node went through some rapid revisions, Babel just broke.
Google's V8 documentation is woeful, and the only way to make quick progress was to trawl through the source code. Professional help would definitely have made the difference early on.
BTW, NodeSchool is another great resource to get up to speed quickly.
The creator acquires no knowledge from what he is creating. He uses the knowledge gained from trial and error to create his product.
If I wrote a story, I can't possibly learn anything new from my story. The story is a result of my knowledge/imagination. Sure I can do research, read other books, ask around, etc. for more ideas, but the end-result (the story) is ALWAYS going to be a RESULT of the knowledge you already possess.
tldr: The creator at one point already possesses the knowledge of how "node.js" works because without that knowledge, he couldn't possibly create it.
Edit: Ontopic
@joepie91
Do you do front-end js too? Or is this mostly node only?
The creator gained knowledge, their proof of concept. People and their ideas aren't Turing tapes... duh.
@joepie91, I'm sure you already know, this is maybe not the best place for leads, but perhaps some older heads may be interested in brushing up on some more modern techniques.
A suggestion, give a free (or free half) lesson for anyone genuinely interested. Care to share how many people have taken you up on your tutoring so far? Maybe list some compelling reasons why people would find nodeJS useful in their tool chest?
$7
Perhaps "viable" or "feasible" would've been better words to use there
This is actually a good thing on a purely technical level. Because of semantic versioning, it's possible to completely change an API without causing compatibility issues - which means there's very, very little technical debt in the ecosystem (relatively speaking).
The problem is that the documentation culture hasn't really evolved along with it. People need to realize that more breaking changes means more need to document those changes. It's slowly getting better, but certainly not at the point where it should be, yet.
Still, compared to eg. Python, the documentation is considerably better, especially where it concerns libraries. It is certainly good enough to not get in your way too often, but it can be a little hard to find direction regardless.
I do have to point out (for the sake of this thread) that my knowledge of V8 internals is rather limited - I understand the fundamental concepts and how they apply to code, as well as some aspects of the optimization, but I wouldn't be able to write a native add-on at this point (and possibly never will be, as I just don't find myself needing to do so).
Here are some resources for it, though, that I've just added to the list.
Yeah, sorry - that's what I was referring to earlier when I said
learnyounode- I keep mixing up the two. As I mentioned, NodeSchool does have some quality issues - in a few cases, I've had to have people 'unlearn' bad habits that they'd picked up through it.I've been thinking about this for a while, but I'm not quite sure how to approach it. The first hour or so is generally spent on understanding your experience level and mindset, and at that point not much is being taught - go beyond that, and it starts taking up a lot of time, especially as it can sometimes take an hour or more for something to 'click' in somebody's mind.
A session works out to 2-3 hours on average, but it depends on the person - there's no hard-set definition of what a "lesson" is, as it's all tailored to the student. In one case, there aren't even any sessions at all - they simply e-mail me when they get stuck, and I bill them for the time spent answering their e-mails.
All this makes it that "offering a half-lesson for free" is not really as straight-forward to do as it sounds at first. The closest thing I'm doing is probably the answering of questions in the #Node.js IRC channel, whenever I get around to it.
I'm not keeping exact counts, but that'd probably be something like 10 people in total, so far? That is including "code review" cases, because the two intersect a lot.
Okay, so, some reasons Node.js works well as a platform:
However, Node.js definitely is not the solution to every problem or project. If you try to use it for financial or scientific purposes, you're going to have a bad time - it's a single-threaded event loop (so heavy computation will stall your entire application), and all numbers are double-precision floating points, which is a problem if you need precision.
The latter is being worked on, though - a proposal is currently being developed to introduce number types with better precision into the language. The "single-threaded event loop" model will likely never change - in the majority of projects, you simply won't need threads, and it greatly simplifies development as there are no thread safety concerns to worry about.
It just means you shouldn't use Node.js (or JS in general, really) for heavy computation.
EDIT: Whoops, sorry, missed a question.
I do do frontend Javascript as well, but it depends on the project and technologies used. I'm highly critical of the whole SPA-all-the-things hype (for many usecases, it just isn't the right solution), and some of the popular frameworks in this area (eg. AngularJS) are awful to work with, and don't make much sense. I've given up on Angular entirely after a year or so, because I got tired of the constant roadblocks.
I've implemented things like (progressively enhanced) AJAX-loading of pages before jQuery was even a stable thing to use, so I am definitely very familiar with the technology and use it on a regular basis - I just don't find most of the popular "frontend frameworks" worth learning or using. A bit too much hype going on in that area, at the moment.
If you want to learn about things like progressive enhancement (and how to implement 'modern' solutions using it) or just JS / web development in general, I can definitely help with that.
EDIT2: Riot is definitely worth looking at for frontend code if you actually need an SPA, and it also supports server-side rendering. React is fine from a technical point of view, but I'm not a fan of its (overly verbose) syntax.
Based on my teaching experience there are several types of learners. There are four types when I was younger:
Over time it is expanded to several new ones:
Many of us are gifted with a combination of number 1 to 4, but many also have a specific learning needs, especially for mature learners.
In public school it is almost impossible to fulfill all students need, that's why there are curriculum and some sets of standards (i.e. qualified football players might have lower passing grades than regulars), etc.
IMHO what @joepie91 offer is another tutoring for specific learning needs with intensive learning - teaching process, so it is up to the learners to get as much as knowledge from this intensive type of learning.
Sorry, but I dont agree with some parts.
Node uses
libuvto maintain a thread pool and handle events. So on the server side, all operations should be written asynchronously, so that you dont block the main event loop. I don't see why you cant max out your cores. More details here.Most scientific software work fine with double precision. Eg - LAPACK/BLAS which lies at the heart of most computational tools. Quad precision can always be emulated with a pair of registers/variables. For the rare cases, you can always use GMP to get arbitrary precision.
For pure awesomeness of Javascript: beyond React, these are some cool projects socket.io, Meteor.
That is why I referred explicitly to heavy computation, not I/O. Yes, internally it uses a thread pool - but you cannot access this directly from your application, and computation in your application is still going to stall your event loop. There exist thread implementations for Node.js, but they are so limited that they're not useful in the majority of cases.
Depends on the usecase, and the caveats are significant enough that I would recommend against Node in those cases. Sure, you can use Node for it, but if there's a significant risk that it is going to be inadequate, why would you? There are better options.
As for GMP - I am aware that this exists. From what I've gathered, support for it in the Node.js ecosystem is lacking to say the least. You might as well use something that supports it better.
I'd strongly recommend against Meteor. It locks you into MongoDB (which is bad), and is extremely monolithic and - in a way - proprietary. Interoperability with anything that isn't Meteor is very poor, and you're going to spend a lot of time trying to work around limitations in the framework (as is the case for almost any monolithic framework).
Socket.io can be useful, but comes with severe performance penalties for using the fallbacks. There's also primus, which provides an abstracted interface over Socket.io-like libraries, that lets you swap out the underlying engine. If you're only targeting recent browsers, it's probably easier to just use Websockets directly.
My server side is mostly native code, so I was working from those assumptions. I thought if you did async Javascript on the server side, it would use a libuv worker thread. Node anyway does JIT compilation when idle, so I dont see why the server side needs to get locked up.
Meteor is awesome, but I wouldnt use it either
Reminds me of the old flame-wars between GNU Hurd and Linux. Technical purity vs practicality.
Yup. Wouldnt touch Mongo with a barge pole either. I use SQLite for my (limited) needs. It can work as an in-memory DB, and now suports JSON natively.
@rincewind I'm currently learning meteor but reluctant due to the MongoDB, so instead I go back using SQLite3 for the good things you've mentioned above.
To be fair, you can use JSON to achieve much the same. I do this for form validation. The JS is fairly trivial.
Any alternative if I don't want to leave Java on the backend and just want to make my life simpler? I think many Java people liked SPA/Angular because most Java based front-end framework (E.g. JSF, Struts) are so slow to code with - and these new tech are way faster productivity-wise.
A very simplified example: calculating a Fibonacci sequence. As this is purely computational, and no I/O ever occurs for it, the work is never handed off to libuv - which means it will stall your entire application for the duration of the calculation, as all work (necessarily) takes place in the main thread.
That's a bit of an extreme example, of course - why would you calculate a Fibonacci sequence in eg. a web application? - but it serves just to illustrate the issue. A more plausible real-world scenario would be calculating some aggregated statistics for an analytics system - even a 50ms stall that happens every now and then is going to cause considerable perceived slowness to users.
Given that every computation stalls, the issue is made worse for things that require extremely low latency (eg. high frequency trading), where the 'resolution' of timing in the event loop (and the accuracy - after all, computation blocks the loop) simply isn't good enough to do anything useful at all.
Most common projects will never run into this, though. It's very common to eg. offload calculation to the database using more complex queries, or use external task queues for long-running tasks.
Well, the thing is that Meteor isn't really all that more practical, it mostly just looks like it is. It has a 'fake simplicity' similar to MongoDB; save a day now, to waste a week later. Once you've built your first project and you are at least somewhat familiar with the modular options in the ecosystem, building a new modular project is going to be far, far faster than building a second Meteor project, because of the 'workaround cost'.
That's also what will bite you in the long run, where it concerns maintenance of your codebase, and adding new features that you might not have thought of when you picked your framework of choice.
Hmm, hadn't seen SQLite JSON support before - however, it seems that while it does offer
json_replace(this is only going to land in PostgreSQL in 9.5), it doesn't have JSON operators or the ability to create indexes on JSON fields yet. That's a bit of a shameAlso, do keep in mind that SQLite has very poor write concurrency. While it works for mostly read-only cases (eg. a blog) and single-user cases (eg. a desktop application), I wouldn't recommend building the next social network on it
Well, fundamentally, it doesn't really matter what you use on the server - as long as it speaks HTTP, you're good. The one drawback is that you can't easily do server-side rendering, which makes progressive enhancement a little harder to implement (and requires usecase-specific implementations - which isn't impossible, just more work).
There are two other options, but both are a little hacky:
AngularJS was pretty much developed for Java developers, as far as I can tell - to its detriment, in my opinion. It tries very hard to emulate Java-ish patterns, even though those don't really exist in Javascript. The result is overly complex code that's shoehorned into the wrong code style. It optimizes for familiarity, not for productivity or maintainability.
@vRozenSch00n : I found these Meteor links useful :
The biggest danger with Meteor, like @joepie91 mentioned is that of getting locked in.
For my own needs, I finally decided on React for the UI, and RESTify for the server side - with the bulk of the backend written in C++. And SQLite rocks!!