CHUCK:
Yeah, you just have to talk to Jessica’s picture. She’s nicer than I am anyway.
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers, providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job but know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept the job. Go sign up at Hired.com/RubyRogues.]
[Snap is a hosted CI and continuous delivery that is simple and intuitive. Snap’s deployment pipelines deliver fast feedback and can push healthy builds to multiple environments automatically or on demand. Snap integrates deeply with GitHub and has great support for different languages, data stores, and testing frameworks. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many more. Try Snap for free. Sign up at SnapCI.com/RubyRogues.]
[This episode is sponsored by DigitalOcean. DigitalOcean is the provider I use to host all of my creations. All the shows are hosted there along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent and their VPS’s are backed on Solid State Drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code RubyRogues, you’ll get a $10 credit.]
CHUCK:
Hey everybody and welcome to episode 228 of the Ruby Rogues Podcast. This week on our panel, we have Jessica Kerr.
JESSICA:
Good morning.
CHUCK:
I'm Charles Max Wood from DevChat.TV. And this week, we have a special guest and that’s Luca Guidi.
LUCA:
Hi all.
CHUCK:
You want to introduce yourself?
LUCA:
Sure, I’m a web developer, a developer from Rome, Italy where I live with my family. I’ve always been interested into web development in my career because I think that’s the future for information technology. I spend most of my career with Ruby since 10 years now. I’m passionate about open source and personal interests like photography and stay away from the computer during the weekends. That’s me basically.
CHUCK:
Cool! We brought you on today to talk about Lotus. You want to give us a quick overview of what it is and then we can dig in and see what it’s about?
LUCA:
Sure, that’s basically my main focus right now on open source. I’ve started thinking about a lightweight version of a web framework for Ruby. I started hacking three years ago now. We wrote those libraries a few times. The main idea was to have standalone libraries for dealing with the MVC problems like Resistance for model or routing directions for the HDP. Then bring them together inside something that resembles Rails but it’s a little bit more lightly.
I started this project because I’ve been a little bit frustrated by Rails. And instead of complaining, I wanted to prove myself that something different was possible. Then when I open sourced the project, I’ve got a lot of feedback from the community. I started to dedicate more and more time and then I’ve recently quit my day job to focus just on Lotus and to reach the 1.0 milestone in a few months.
JESSICA:
Wow, that’s pretty exciting. How did you get to quit your day job and work full time on open source?
LUCA:
That’s basically for now I’m doing unpaid work, just because it’s something that I love. For the last three years when I started Lotus, I enjoyed more of the time that I spent on it rather than doing paid job. I said, “Why not follow the passion?” My passion is just for a few months, think of something doable.
If you save just a little bit of money in advance and then you can focus on your dreams, on what is interesting for you and that’s what I’m doing right now. Aside from that, I’m trying to again get away from my computer during the afternoons or during the night which it wasn’t possible for me having a day job and an ambitious project like Lotus. So that’s the thing. Everybody can do it. Again, I have a family. It’s just a matter of saying, “Okay, that’s enough and let’s do this.”
JESSICA:
Awesome.
CHUCK:
So I’m curious, I do a lot of Rails work. Most of the applications I work on I would say are in Rails. What is it about Rails that you didn’t like or what is it about Lotus that you wanted to see?
LUCA:
That’s basically what I call flat and be seen in the Rails. That means having skinny controllers and [inaudible] models. Try to overload all the MVC layers. I’m more advocating for with Lotus to keep your applications maintainable since day one and do not try to overload the MVC layers once they’re going to explode. I’m talking about the models I’ve seen in my career, models with 500 kinds of code or more and the same thing was true for the controllers.
So I’m trying to bat on software maintenance and to make Lotus, and to bring in the discussion in the community productivity versus maintenance. That means not just focus on gems that you can install in your application to get your features out faster. But to sit and think, “Hey if I’m going to work on this codebase on one year, on the next five years - is this a sustainable phase for my application development?”
JESSICA:
Sustainable phase, that’s a great goal. Can you tell us what is it about Lotus that lets applications written in Lotus be more maintainable than Rails?
LUCA:
Yeah, that’s basically the thing is that it tries to mark a clear separation between the MVC components and inside each layer of them, a clear separation of the main roles. For instance, in the model, there is a separation between the persistence and the entities which are basically your model domain classes, objects. Having this kind of separation helps to clarify the intent of the single components and not have a coupling between those components.
It happened to me in the past that running a Rails migration broke a web form because there is a tight coupling around the data. For Lotus it’s totally different. It’s more focused on the behavior that your components have and last about around data because we are trying to put object oriented and behavior in general. They use cases around in the middle of the focus of developers rather than focusing on resistance and data.
CHUCK:
That’s one thing that I really liked looking through the code in the example. And fiddling with Lotus a bit was that you have the idea of entities and then you have your repositories. The entities are basically your models and the repositories are the data sources.
So you’ve got Postgres in the example here where you’ve got basically a Postgres URL that does whatever work. The more I thought about it, the more I fiddled with it, the more I really liked it. I know people have tried to do this with Active Record. Basically they use Active Record as the repository and then they use Ruby classes that hook into Active Record as their model or entity.
The issues that I’ve seen with that are basically that there’s not a good connection, I guess, or a good convention around connecting those entities to the repository using Active Record as the backend. With this, the way that you have things pulled together, it’s really pretty seamless. There’s a little bit of configuration you have to do rather than just the convention for hooking that up. But it takes away a lot of the magic and it makes a lot of this. As automatic as it can be but still allowing you to be explicit about how you approach your model layer.
JESSICA:
Oh, I really like that because when you remove that convention and yeah, it might be a little more for Boost but if someone can actually follow the code without being immersed in Rails lure, that’s a big plus.
CHUCK:
Yeah, I think there are tradeoffs there. Sometimes the Rails magic is nice because you just point it at the database and it works. But the flip side of that is that if the convention isn’t what you need or if it’s really far away from what you need, then it’s really painful to make it work the other way because you’re basically fighting against a lot of assumptions that have been made about your code.
LUCA:
Yeah, in general my opinion about frameworks is that they can cover the most common cases that a developer can have for their application. Of course, conventions are great. But again, I wanted to give the possibility to developers to configure the behaviors that they want to emerge.
For most of the time, the verbosity is also a tool, a self-documenting tool. For instance, there are places where the code lives on and that is the convention that Lotus offers for the 90% of cases. But then instead of monkey-patch Lotus in your application, you can just change the configuration that it offers and it’s in your phase. The bottom line is that explicitly it’s better than magic because it helps developers to not fight with the framework itself. That’s the thing.
JESSICA:
I totally agree.
CHUCK:
One other thing I want to talk about here, because if people jump in and they start playing with Lotus, it is definitely a different flavor than Rails. It’s a different flavor from Sinatra. It’s a different flavor from Roda. I don’t know that I’ve used the framework that’s quite the same as this. In fact, if there is any framework that I think or any coding that I’ve done that’s anywhere similar to this, I think trailblazer which adds a bunch of stuff to Rails, gets close in some ways. In some ways, it also reminds me of how you build iOS apps in the way that they organize the code.
One thing I wanted to talk about was you have views and the views are not the templates. The views are actually a class that sets up which view you’re going to use or which template you’re going to use and can manage some of that. It almost feels like MVVM where it’s Model View ViewModel except you actually have controllers in here, too.
Do you want to explain a little bit of the structure there and the relationship between controllers and views in Lotus?
LUCA:
Yeah, and that is the case to talk about conventions right now. That means the view, there’s a structure in the naming of the views and the actions. So at runtime if you have home action, it will look for home view. The view is a Ruby class that holds all the behaviors for the presentation. Then it can have one or more plates associated. That means you can have or you can generate HTML [inaudible], HTML whatever.
And the reason why the views are there is that I wanted to make the templates which is on erb file or Haml file as clean as possible for this entity of code maintenance. And because once you have the code, the presentation of the code extracted in a view, you can easily have unit test view and it’s possible with the Lotus. You can unit test a view and you are sure that the behavior, presentational behavior or the conditionals for instance for the permissions of your applications are well unit tested. That’s it.
CHUCK:
So besides testing, what is a cleanup on the view that is difficult in some of the other frameworks or things that you’re going to use?
LUCA:
Basically because you have a place where to put presentational code, you are not tempted to clutter the templates. That’s the main point. Talking about again about the relationship with the corresponding action, you have all the exposures. That means there’s a set of data that comes from the action. It’s available inside the view and you can use inside this object.
You have set of helpers which are private methods. That means you cannot use something like formatting helpers in templates because I wanted to avoid again, I wanted to avoid a clutter, clutter at templates. Again, the bottom line is that it’s for code maintenance. That means clear templates and the stability of presentational logic.
JESSICA:
Forgive my ignorance. In Rails, do you sometimes wind up with code in the template like conditionals and things?
LUCA:
Yes, that’s it. That’s the problem that I’ve seen in most Rails applications is that most of the time, presentational code is made from [inaudible] conditionals are made in templates. That creates hard times to maintain that template and to test the conditionals where sensitive tests are needed.
For instance, when it comes to talk about authorization of resources, if I can show or not a button for a common user or they are an admin or a [inaudible]. So, that’s the thing that I wanted to offer, a place where to put the presentational logic.
CHUCK:
Yeah, what you see in Rails is that I think traditionally a lot of that presentation logic would go into helpers but the helpers aren’t scoped anymore to a specific request or a specific controller. So you wind up making all of that logic global even if you don’t need to.
The other issue is that you don’t really have a good place to put presentational logic that you only need for one view anywhere that’s convenient. So you either wind up handling it in your controller or handling it in the template. Neither of those are really great places for it.
So if you have something like this where this view acts as a presenter for your template then you can put the custom logic in there and then it just behaves and does the right thing because you’re calling something that you have only exposed where you need it.
JESSICA:
That’s nice. I do like the trend that I’m noticing. React is another example of this for taking the code out of HTML, out of templates and instead putting HTML in the code if we have to.
CHUCK:
Yeah, I’ve definitely seen that on the frontend where you’re talking about React. I’ve seen a lot of people doing it with other templating systems where they basically compile the information into HTML templates that they use through their JavaScript with Angular and Ember. Yeah and then they just make convenient places in their directives or controllers or whatever routers and backbone where that information is all scoped and neatly contained. So that when you have to do something, it only really affects the areas that you’ve designated as the area of concern for that piece of code.
LUCA:
Yeah and speaking of the helpers, that is another thing that I didn’t like and I wanted to change for Lotus because they represent, as you say they represent a global state. When something goes wrong, you don’t know where to debug.
I want to make developer experience really pleasant. So if something goes wrong and you have a stack trace to look at, you can be sure that with Lotus, the view is the only context for the rendering of the template. So you have good… and the only starting point where to look at instead of digging inside the framework or digging inside the helpers that aren’t a concept. There are helpers in Lotus but they are a different concept if compared with Rails.
JESSICA:
That’s fantastic. Better error messages are so helpful.
CHUCK:
Oh yeah, always. I hate to say always about code but yeah.
JESSICA:
Well pretty much.
CHUCK:
I can’t think of an instance…
JESSICA:
We don’t want about the happy path as the common case but that’s only from a user perspective. From our perspective, the happy path is rare. We get there and we stop but the errors are myriad.
CHUCK:
Totally. I also wanted to talk a little bit about the controllers. Looking at this, they almost feel like Rack apps where you have a class and you exposed call on the controller. I don’t know if that’s your intent or if it was just a convenient way to use a convention in Ruby where if you exposed an object that implements the call method, that you can do interesting things with it.
LUCA:
I wanted the learning path for developers to be short at the beginning. The controller layer was one of the first components that I wrote. I said, “Hey, if someone knows about Rack, she’ll know about Lotus actions. That’s the bottom line for that.
The side effect is that if you expose an object that accepts, that response to call, it can be a proc or [inaudible]. That’s a side effect of that choice. But the main one is to have an easy onboarding for people because I believe that having a short learning path can help not just for Ruby developers to try it but can help newcomers.
For instance, people who are learning how to program, to learn just a little bit about objects. Then be able to use a Lotus action or the other components or other developers from other languages that are a little bit intimidated from the Rails magic. They have a ton of [inaudible] who are not using Rails and Ruby in general because they don’t understand a lot of our common patterns. We are used to because we live in this community since years now. We are used to understanding the old conventions that are in the libraries that we see around. So I think we should make life easier for those people.
JESSICA:
That’s great. I love that you’re thinking about that, about the [inaudible] for people who aren’t just like you. We often take for granted how much context we have, how much we know, that makes these things easier for us and not just for the rest of the world. So thank you.
LUCA:
Sure.
CHUCK:
One other thing I noticed working in Lotus was that the validations. In your example, you have a book and you have to create action. The validations are in the controller not in the model. Do you worry that you’re going to have to repeat that logic in other places where maybe you have book parameters coming in from other sources?
LUCA:
Lotus in general is used-case oriented. That means that I think of software web development in general not just with Lotus like [inaudible]. For instance, a user needs to complete an action which is a used case. It goes through the view and the action and down to the database. So I spotted this pattern that we tend to push variations inside the entities or the record models, whatever. Then those validations are not universally true across our code base.
I give you one quick example in an application that I work with that was a user that can’t sign up and the password is mandatory. But this user can be also invited by the admin and the password there is not mandatory when you’re going to process. So we have to use cases and different sets of validations. So I wanted to expose validations where I think they are really, really useful. That means in the server side code, the outmost server side code that can handle that. In this case, they are in the actions.
So there is no need to hit the database or try to hit the database if at the beginning if the parameters that I see from the user input are not formally valid. And I’m talking about for instance say the age is not meant for a user or the password is not matching, all those kinds of things I think can save a lot of CPU cycles if we reject bad input at the beginning of the used case. And then the below layers that an action can use can be sure that the data is valid. They can operate on it. That’s the thing. It’s like a guard inside the method. When we reject, we don’t go for the expensive competition where we know that for instance the argument that we received is little.
CHUCK:
Yeah and to be honest, when I first saw it I was like, “That kind of feels right.” But then yeah, what occurred to me was but yeah, everywhere I take book parameters, I’m going to have to validate them. Is there a way to validate a collection? So let’s say that somebody passes several book parameters?
LUCA:
Not yet, because I want them to be sure that this was a valid choice. But I’m thinking to offer a little bit more options for this kind of validations.
CHUCK:
One other thing that I really like about your example was that you start out with a test and then you say, “Okay, now we’re going to make this test pass.” Then you start out with the next test and you’re going to make that test pass.
Is there a reason why you approach it this way? It looks like you’re using capybara.
LUCA:
Yeah because I said that most of the tutorials are there. They just code their production code. Then when you’re new especially with the languages that you barely know then you have hard times to understand how to test things. With a language like Ruby where you test both for testing the behaviors and at the same time, you test that the software is formally right because you don’t have a compiler to save the situation. I wanted to in general, with all of this I want to put a lot of emphasis on the BDD and testing in general.
Yes, the example report is capybara. That is a personal opinion that is leaked inside the Lotus decisions. Again, I’m a fan of BDD. That means when I start writing a feature, I use capybara to prove that the feature is working. Then I go down writing the innermost level of test that is unit test. So that’s a personal opinion that I tested a lot in my career, in recent years in my career. It’s proven to work great and I wanted to offer as a solution for Lotus.
JESSICA:
I’m curious, what do you love about BDD?
LUCA:
Confidence.
JESSICA:
Confidence?
LUCA:
In one word. That’s the thing because most of the time, if you just have the unit test you lose the big picture. You are not sure that your application is working correctly. You have just to prove that your single components are doing what you want to do. So it’s different when they play together. You discover flaws in your design, stupid mistakes that may happen during development. So again if the feature test with capybara passes, it gives me the confidence to ship to code in production.
CHUCK:
One other thing I want to just throw out there is that a lot of people have the subversion to end to end tests. With capybara, if you aren’t running through Selenium or PhantomJS or something. Those tests actually run over Rack test which creates its own interface that it makes the calls through. Those tests run actually pretty quickly.
So in my experience, they’re usually well worth riding if you’re doing like some single paged app for something that has a lot of frontend processing, that’s when your end to end test or acceptance test gets expensive. So this is a really good example of how to test an application written in Ruby in a framework based on Rack.
JESSICA:
That’s great. The Behavior-Driven-design, it totally helps you find those bugs because I agree with you, Luca. The bugs are usually at the seams. They’re between the components not within them.
Also, I think that kind of testing gives you when you’re looking at the test, it gives you a much better perspective of why you’re doing any of this.
LUCA:
Yeah, it’s not just why you’re doing that but again it helps. Because you are putting yourself in the user’s shoes, you understand the choice that you make day by day in design between your components.
Again, it’s more about boundaries rather than complements themselves because a component can have a decent design if you look at it in isolation. You say okay whatever. An object needs a class. It’s whatever. With them, when used around that object with the collaborators, the ground changes a lot. Then you discover if your design is good or not. That’s the thing that happens for me with BDD.
JESSICA:
Yeah, that’s true. Design is only good if it’s good in its context. I also love Chuck’s point about how maybe you hate integration tests because they’re slow. But if you move the test boundary down just a little bit, so that going over the network is not inside your test boundary. You can do a lot more testing faster.
LUCA:
Yeah but Rack test helps a lot with speed up your integration testbut sometimes again, if your application does a heavy use of JavaScript and most of the time we don't have JavaScript, that it's the only way to check that. Again, to prove that it works. Sometimes, I have to confess that I was in a rush. It happened that lately I was in a hurry to ship one feature and Phantom JS was just acting. I don't know what happened. It crashed with my Ruby VM. Then I discovered the test.
But then the second thing that I rely a lot on are unit test for used case service objects because if you are not able to prove that the wall stack works fine for some reason, you can understand that at least the business logic works by testing the service objects. That's the other thing that gives me confidence when it comes to talk about shipping features in production.
CHUCK:
I have another question about the API for Lotus. Just looking at the models and fiddling with this, I never could quite figure out how to build either entities that referenced each other. So for example, you have associations that are kind of magic on automatic in Rails and so yeah, I didn't see associations.
The other thing that I see that could be very powerful with Lotus and the way that it does entities is sort of a composite object. I've done this before where you have a user or maybe a profile. So you might have some entity that's like a user with profile and it has just a few other convenient things that you wouldn't necessarily need if you just had the user or just had the profile.
Is there a way to do associations and/or some kind of composed object or composed class?
LUCA:
Associations are right now in the making. We're supposed to ship with this release of today. But then we had to postpone with the next release because we wanted to test a little bit more this feature. Then aggregate with something that I was thinking for a long time but that I haven't formalized it yet, an API for that. It's something really interesting to investigate in the near future.
CHUCK:
One other thing that occurs to me is that the way you have the model set up, it might be nice to pull something like this into Rails. I think it would be relatively painless, of course I may be wrong on this, to pull it into Rails and not have to write a whole bunch of glue code.
So is there a separate gem for just the model logic?
LUCA:
No, there isn’t a gem for that because again the API is young. I'm trying to take a slow approach on API because even we are under 1.0, I respect developer's patience. They're willing to hack with Lotus. I didn't want to change too much the API. So once we reach a stable API that again should happen in a couple of months, we want to focus on two things.
One is the ecosystem for reasons we have in the past. We have issues with the [inaudible]. Right now, we are debugging one issue with pry-debugger and so on. We want to focus and make Lotus not a happy island in the Ruby community and the Ruby ecosystem but to help, to be more usable outside of the Lotus itself.
For instance, if you want to deploy on your work, there are progress to make Lotus a good Ruby citizen. So that's something that we will see in the future for sure. But I'm not sure about the Rails situation. I want to focus on the core components of Lotus for now and I see this kind of thing as a third party gem.
JESSICA:
If someone wanted to help with Lotus, what could they do?
LUCA:
Right now, play with it. That's the thing because we are almost done with the features. We want to understand if our choices are good or not, if they make sense. And we have a great deal with big companies that are trying to build stuff with Lotus. They deployed in production. And we got feedback from them. We want to get more and more feedback in the near future to criticize us, criticize the challenges and spot the problems that there are for sure in the software because it's still young. So, first thing is to try it. Try to break it and play with it, hack, and try to understand if it makes sense.
The second thing is about companies are brave developers. Again, we have a few of them. It's to use Lotus for something. They're not critical right now because again we are not 1.0. For instance, something like a small internal service to play with it and to see if it's good or not, if developer experience in the deployment experience, the runtime experience is good for them or not. That's the thing, feedback, feedback, feedback.
CHUCK:
By the way, I just want to point out on Coraline's behalf that there is a contributor code of conduct. I know that's a big deal. Thanks for contributing to the community this way as well and letting people know that there is a certain level of expectation as far as the way we treat each other.
JESSICA:
Yeah. And some of those who try Lotus and they have some feedback for you, where should they put it?
LUCA:
We have a forum which is discuss.lotusrb.org. And there is a Gitter chat where we discuss all day long about Lotus and we offer help to people who are stuck with some problem. They are both linked in the readmes of all the chats.
JESSICA:
Thanks. One thing you mentioned was that with Rails people are encouraged to just download gems like crazy to get their features out. If people are using Lotus in the spirit that you intended, do you think they would download fewer gems?
LUCA:
When you install Lotus, you just install a few gems. I encourage you to do that and see how a few gems you get for more or less the same features, they've compared it with the Rails because I see now tons of times to contributors who want to install gem for something internal. So it's not just about a technology. It's about a mindset. That means most of the time, I've seen former colleagues to just install a gem that means install a lot of runtime code and make your CI times slower, your bundle of times slower for just a couple, literally a couple of lines of code that you needed from the gem.
So I want to advocate to pay more attention on what we install because we are kind of adopting a kid, a child because Ruby relies a lot on volunteer work from the community. If the maintainer of the gem that you install loses interest in the project, you're stuck. I've seen this problem a lot especially when you need to upgrade a bunch of them. So I want to advocate that to be more conscious on what you put in your application. And of course if you need 5% of a gem, you can just write yourself. If you need 60%, 70%, of course for your sanity gem install full. And that's my philosophy.
JESSICA:
I think that's great. I think one of the dangers in the Ruby community is the tendency to just install gems willy-nilly. It's easy to do but there are consequences that you don't see until much later. Running other people's code, I love what you just said about downloading a gem is like adopting a child.
CHUCK:
[Laughing]
JESSICA:
It really is. Those responsibilities, they don't end with the download. They end only when you remove that code from production.
CHUCK:
Is that like the saying, "There's no such thing as a free puppy"?
JESSICA:
Yeah.
LUCA:
Yeah.
CHUCK:
You have to feed it and take care of it. Yeah, I mean ultimately, you're responsible for your app working, right? You can file a bug on whatever gem you pulled in to add functionality but at the end of the day, I mean for my clients, they don't care. If I pull in a gem and it has a bug and it's not doing what it's supposed to do, it's my fault. It's not the gem maintainer's fault. I can't pass the buck.
JESSICA:
And that gem is something that everyone who goes to maintain your code has to understand.
CHUCK:
Yep.
JESSICA:
If you're familiar with it already, that's free for you but costly for anybody else.
CHUCK:
Yeah. The flipside to that though is that there are gems that add convenient functionality that you don't have to do a whole lot of work to get to. But yeah, you have to be aware of the other tradeoffs. And I think a lot of times, we ignore those.
JESSICA:
Yeah. If you need that 5%, cut and paste if you have to.
CHUCK:
Ooh, That's illegal. I'm just kidding.
[Laughter]
At least then you own the code, right?
JESSICA:
Yeah, at least then you have exactly the code you want and hopefully you read it. Maybe you even cut and pasted the tests, that would be the industrious but..
CHUCK:
Ooohh.
JESSICA:
I wish instead of having to add a dependency to my project, I could just get the code, get the tests of one function at a time.
Anyway, I think Luca's philosophy on Ruby is really constructive and I'm glad you're encouraging that.
CHUCK:
I love the ways that we can go in and play with the way that we organize our thoughts around this. Because I mean at the end of the day, we're writing web apps that people can use whether they're written in Rails or Sinatra or Roda or some other language. But because it's a different way of thinking about it and a different way of solving these problems, we can use it. Then we can come up with better ways of organizing our own code even if we're not going to wind up using Lotus.
JESSICA:
Yeah, learn some of what Luca learned with all of his work building it.
CHUCK:
What have you learned building this, Luca?
LUCA:
Oh, a lot of things. For instance, from the technical perspective, that it's really, really hard to write a correct software with Ruby. That means that Ruby is a great language. It's so expressive and at the end of the day, I love it. But sometimes there are some pitfalls or some implicit behavior, say in the language that you need to test while building a framework like Lotus because if you don't test those kinds of things, for sure there will be a bug in a few months.
For instance, if you expose a hash or array with attr_accessor, you need to make sure that the readers, the accessors, the outside code, let’s say doesn't mutate that hash. And it's something that the 90% of Ruby developers that I know but keep forgetting. That hashes and arrays are mutable from the outside of an object if you test them. So if you expose a hash of information, you need to duplicate so it doesn't mutate internally. And this is really, really hard to remember. And we are not educated. The average Ruby developer is not educated. In my experience of course, it's not that he or she is not educated to this kind of attention.
From a human perspective is that running alone is so tempting but running together, it slows down but it makes you a better person and at the end of the day gives you better software. Probably I will give a talk about my experience with Lotus and managing open source communities. And it's a matter on how you communicate your philosophy about gender diversity, about paying attention on those details that are really important, really important values that you want to communicate to the community. Because open source is not just software but it's the community around, it's the politics that you get across your users.
JESSICA:
That's so true. I mean, we like to think of software as just code but it's not just code. It's the people who use it, the people who write it. Yeah, it's all of us. What is your philosophy?
LUCA:
My philosophy about software, it depends on the community that surrounds it. I'm talking about… especially I'm talking about open source. If you make it right, you can grow your community with different values. And this is something that you can observe on several technical communities. This is something that you can also observe on several technical communities.
I love Ruby community because it's filled of really, really nice people. I think that there is room for improvement, to feel everyone welcome and safe inside the community. And if you look from this perspective, software itself is just a detail because it's more about the people and not about the code. That's the main reason why I decided to open source Lotus early on and try to embrace this philosophy and build the Rails community with this philosophy. To prove that it's possible to have nice values and decent software, let’s say.
JESSICA:
Thank you.
CHUCK:
So what's coming next for Lotus? What are the features you're adding in at this point?
LUCA:
Associations between entities. We are pulling in the mailer which was part of the Rails gear summary code. We were a technical partner where two students from Coimbra, Portugal who implement that mailer gem from scratch, so thanks to them. We were a lot excited about this thing.
The other feature that we are working on is the integration for the assets. And that's it basically because we want to focus on code stability. We don't want to pull in five other features. We are looking to make it more robust and to make the path to 1.0 a little bit shorter that we were planning at the beginning. Because meeting people at the conferences, they are demanding a lot for Lotus 1.0. It's a catch-22 situation because they don't want to use because it's under 1.0. But we demand for feedback from them. So we want to be brave and release 1.0 once it's stable enough in a few months. Then we can add the features that we have to postpone in those months, for instance, WebSockets.
I came out with the solution for WebSockets but I'm not happy with that. It's not scalable and I decided to keep on hold and add it after 1.0 because we want to offer something that we truly believe can work in production rather than ship it and being not responsible for our developers.
The other day that's coming for Lotus is a hack day for collecting feedback, one to be held by the end of the year. We put on a landing page for that and to collect people who want to join this hack day. So if I heard a lot of developers that keep telling me, "Hey, I want to play a lot with Lotus but I
don't have the time." So I want to eliminate this excuse and organize this hack day where they can play with all this for day long, building something to ship in production in one day. So we can have a lot of developers who try it. We can have the social aspect. We can have feedback and that is crucial to me as a path for 1.0.
CHUCK:
Alright. Well, I'm excited to see where you go with this.
LUCA:
Yeah, it's exciting. At the beginning, I was thinking to wait for a long time before 1.0 because I want to not change every error the API of the main components because of my focus on the maintenance. But I thought that probably was a brave solution to have 1.0 soon out and see what happens. I'm a little bit scared but it will work great, I think.
JESSICA:
Great. Thank you so much for all the work you've put in this, for running a community consciously, and for taking time off work to bring Lotus to 1.0.
LUCA:
Yeah, it's a pleasure because I believe in open source. I believe in communities. It's a dream for me [inaudible]. It's also a privilege for me to work on that. I'm happy to be focusing just on that. I hope that it could be a nice experiment for the community to have. And thank you to you for having me today.
CHUCK:
If people want to follow up with the project or with you or give Lotus a try, what should they do?
LUCA:
There is the website, that's lotusrb.org and there we have a mailing list to follow with the updates. We have the chat. We have the forum. We have Twitter and everything is reachable from the main website. We have a blog there. So there are several channels where people can get up-to-date with the progress that we are making during these months. We have guides for all the components that help to write the first Lotus application in [inaudible] or so with all the explanation on how to test it and so on.
CHUCK:
Alright then. Before we get to the picks, I just want to acknowledge our Silver sponsor.
[This episode is sponsored by Code School. Code School is an online learning destination for existing and aspiring developers that teaches through entertaining content. They provide immersive video lessons within browser challenges which means that each course has a unique theme and storyline and feels much more like a game. Whether you've been programming for a long time or have only just begun, Code School has something for everyone. You can master Ruby and Rails through JavaScript as well as Git, HTML, CSS and iOS. And more than a million people are on the work to use Code School to improve their development skills by learning or doing. You can find more information at codeschool.com/rubyrogues.]
CHUCK:
Jessica, do you have some picks for us?
JESSICA:
I've one pick. I really, really like the game Threes on my iPhone and it's probably available for android and on the iPad. And I've always liked it. It's kind of like 2048 only better. It's like 2048 is a copycat of Threes! And Threes is a little harder and way more interesting. It's just a beautifully created game because the numbers, it's just like you put two numbers together and they make bigger numbers. But the numbers have personality. And their music is really good and their little numbers, they talk to you and say hello. It's a game that someone put a ton of love into. It's a simple game with character and passion. Just as a creator of software, I really appreciate this game for all those little touches. That's it. That's my pick.
CHUCK:
Alright. I've got a couple of picks. The few number of things that I've got going on; one is that I've been connecting with a lot of people over Twitter and LinkedIn. Basically, I mean just having direct message, chat kind of things with Twitter and LinkedIn. So if you want to connect with me on those, I have just been really enjoying, like I said making connections and learning about who the people are.
You can also go to RubyRogues/15 minutes, that's RubyRogues/15minutes and you can get 15 minutes of my time. And I've just been hopping on and talking to people. I've been trying to get to know people personally, personally as much as you can in 15 minutes. Also find out what you like about the shows that we put together here at DevChat.TV.
So, I can't say enough good things about our listening audience. We have such great people listening to the show. I just want to shout out to everybody that I've had the chance to talk to you, especially the people who are pretty new to development because I know that some of you were a little bit intimidated to talk to me. Hopefully I was able to seem somewhat human when we talked. I really just appreciated all of the feedback and just to be able to get to know some of the people who listen to the show.
I'm also pulling together Rails Remote Conf. I did Ruby Remote Conf. back in June and I'm going to be doing Rails Remote Conf. It's going to be November 5th through 7th and you can get the details at railsremoteconf.com. If you use the code Rogues then you can get 25% off. The early birds tickets are going to be available through October 5th. They'll be $100 and they go up to $200. So you want to get your tickets pretty soon here. Anyway, go check that out.
Finally, so back when I was spending money I didn't have, I backed the Pebble Time kickstarter campaign. I just got the watch in the mail. It's a smart watch. It's kind of like the apple watch. It doesn't do like the fitness tracking and stuff but it does the notifications on your wrist. There are bunch of apps in the app store that interface nicely with Pebble Time. It also hooks up with runkeeper and a few other apps that I already have on my phone. Anyway, I've really been digging it. I've had it for about two days and it's really nice. It comes with a nice leather band. I actually backed it to where I get a bike metal band but I haven't gotten that yet. Anyway, I'm really, really liking it.
I also see why people would like the apple watch since the integration is a little bit more seamless there. But yeah, that's what I've been playing with the last day or so. And like I said, I'm really, really enjoying it. So I'm going to pick that, too. Luca, what are your picks?
LUCA:
I've got a couple of picks as well. One is related to Ruby which is [inaudible] which is an initiative that PiotrSolnica put online last year. It's a movement about small and focused on gems - gems that are under 500's line of code. They're really tiny [inaudible]. They do just one thing and do it well in the unit's philosophy. It's something that deserves attention in our community because it gives example of great code.
The other pick that I have is about a painter. He is a Vietnamese painter but he lives in the States. His name is Duy Huynh. I am enjoying his paintings lately. My wife discovered him and we got a couple of paintings of him. When I need to relax or pause a little bit, I just lose myself in those paintings. I'm really, really enjoying his file.
CHUCK:
Very cool. Alright. Well, thank you again for coming, Luca.
LUCA:
Thank you for having me.
CHUCK:
It was a great conversation. Hopefully, some folks will go check out Lotus and let you know what they find.
LUCA:
Yeah. I hope. You are really, really welcome to talk with me and with the rest of the team.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]
[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]