Michael Swierczek

Bear Bibeault wrote:For the uninitiated, info on Reactive programming.

Thanks. I remember at work two years ago we had a hideously complicated web form. There was all of the usual input field validation, a few Ajax calls, eight or more conditionally hidden sections, and a few dozen input fields that were conditionally enabled based upon values in other fields.

We tried to develop it with a colossal set of 'if' statements, but it was a buggy and broken mess. Finally I gave up and started over with a giant JSON data structure. The main keys were the HTML IDs of every element on the page, and the keys linked to an array of HTML IDs of dependencies for hide or show (if any), then an array of HTML IDs for dependencies for enable/disable the field (if any), and then an array of custom functions to call when the value of the field changed for validation and Ajax calls and other custom computation (if any). Then we just attached a single event handler to the entire page that would traverse the JSON object and apply all detected changes based on the state of items, and then return the number of page elements that were changed by the event. If the result was 0, it stopped. If the result was greater than 0, it ran the event handler again to handle cascading changes.

The whole thing was certainly grossly inefficient and I wouldn't be surprised if I slowed old machines with IE7 to a crawl. I'm sure someone skilled with high performance Javascript would have read the code and had a seizure. But it took it took less than a week to write and test to smithereens, and as far as I know it's still in production.

Wow, thanks for taking the time to write such a detailed answer. I'm satisfied with all of the responses, thank you.

Stephan Hochhaus and Manuel Schoebel,

Again, thank you for participating in the book giveaway. I have a few questions, in no particular order:

1. One of the only advantages of using a programming language other than Javascript on the server is that it's easier to remember that on the server side you need to (re-)validate all data coming from the client. I try to write all of my validation in Javascript because the website is easier to use and more professional when entering a name into a date box generates a pretty red notification for the user. But if the error - accidental or malicious - gets past that Javascript, I still also run a check on all of the inputs and session roles for protected resources on the server side in my Java code.

Does Meteor make it simple to keep track of the difference between client side validation and server side validation? My first fear would be that I write some validation code, and it turns out to only run on the client and someone can bypass my entire security layer by sending a bad request using raw socket programming or web browser developer tools.

2. There have been a lot of articles floating around the web that criticize MongoDB for scaling. Now first and foremost, I realize that having a scaling problem is the right kind of problem. If I write a Meteor app for work or on my own and I'm having trouble now that I have 10GB of user data, then I probably have a business model and I can cross that bridge when I get to it. But I'm just wondering if you've run into any issues like that, and if not then I'm just curious what size data sets you've successfully used with Mongo.

3. I see chapters 5 and 10 of your book are on reactive programming. I'm just wondering how your experience with reactive programming has been. I see it's gotten a ton of hype over the past two years, but I'd like to hear from you - or anyone else that cares to chime in - how it has simplified client code.

Last, I see from Stephan's short author biography blurb on the Manning page for the book that he has worked with Java, C#, and PHP for web programming before moving to Javascript. I'm just curious - if you had to use a language other than Javascript on the server, what would you pick and why? I'm not fishing for a particular answer, I'm just interested in how other people think. I also see that the two of you run Meetup groups for Meteor - cool.

As an aside, a brilliant colleague of mine resigned his full time position in January to work as a contractor on Meteor. He's been raving about it and doing part time contract work with it for over a year. (Thus my interest in your book.)

Again, thank you for your time.

Welcome Stephan Hochhaus and Manuel Schoebel. Thank you for participating in the giveaway.

One suggestion I have for anyone interested in the book - there is more information available on the Manning page than the Amazon page. http://www.manning.com/hochhaus/

Ha, I should have known you would be familiar with it. Cool.

( http://shop.oreilly.com/product/0636920036593.do for anyone that hasn't seen it )

That's hilarious. I love it. Did someone else come up with it, or was it all you? I'm just curious.

Thanks for participating in the book giveaway.

(Edit: I respectfully suggest, for any Ranch admins, that the site link to the book go to the OReilly page instead of the Amazon page. If you have financial incentives or contractual obligations to link to Amazon, I understand. But I think the video and the PDF preview on O'Reilly make a much more compelling sales pitch for the book. )

Oh sure, make my life seem even more boring than it already is.

I studied and practiced using your book on SCJP for Java 6 to ace the exam on the first try, so thank you.

On the science of motivation - different from, but of course related to, the science of learning - I found the book "Punished by Rewards" by Alfie Kohn fascinating. He's not an interesting writer, and that really hurts his message. But he manages a very powerful deconstruction of traditional punishment and reward motivation methods. I thought it might be interesting to you, if you haven't encountered the ideas already.

Thank you for participating in the giveaway! Cool.

Rami Sarieddine, thank you for participating in the book giveaway.

I understand that Promises are an escape from the nested callback headaches you get in a lot of Javascript code. I am curious if your book includes recommendations for how to structure a Javascript application differently now that this tool is in available.

I'm also curious about the implications of promises for writing applications in Node.js or Meteor.js. Do you have any thoughts on that?

Thank you for your time. The free sample material from Packt Publishing was well-written and easy to follow, even for someone like me with Javascript knowledge barely past the novice level.

Aleksa Vukotic,

Thank you for the quick and detailed response.

Jonas Partner, Aleksa Vukotic, and Nicki Watt,

Thanks for taking place in the ranch book giveaway.

I am experienced using traditional SQL databases, but I don't have a strong background in the related theory. My knowledge of graph theory is even weaker. I'm trying to understand how you would run analytical queries on Neo4j, and how well it would support them. To use the social network as an example, is it easy to say, "give me a list of all users and the number of friends they have, ordered by the number of friends, descending" (which of course is trivial to do with an SQL select)? Does it perform fairly well for that? If the Neo4j graph stores the date a relationship is established, could I write a query equivalent to, "How many people on the network added 30 friends in March 2014?" ?

That's my main question. As a minor question, I'm curious what the largest Neo4j data stores in production, that you're aware of, are.

Thanks for your time.
-Mike

Thanks for participating in the giveaway! For anyone that hasn't seen it, the Manning.com web page for the book links to some free sample material, http://www.manning.com/partner/ including the first chapter of the book: http://www.manning.com/partner/Neo4J_meap_ch01.pdf

Fair enough. I can't release private code, so we'll have to leave it at that. Thanks for the discussion, I appreciate it and enjoyed it.

I am miscommunicating something. The problem is that many dozens of non-homogeneous pieces of state need to be passed around. If you use a POJO, you've got a colossal POJO and another form of the same monster object problem that we already have. If you partition pieces of the data into smaller groups, you either need to pass them around in an HttpServletRequest attribute map, or something similar, right? Then you have the type-casting / instanceof problems. Right?

We're using Stripes.

The problem with doing work in the ServletFilters is that you have to stick all of your objects into the HttpServletRequest or HttpSession attributes, right? Then at the next ServletFilter step, or in your final Servlet class, you have to do lots of getAttribute() calls and then some instanceof checks on what you get. Am I missing something? Doing everything in one place has (many) headaches, but you keep your type safety everywhere.