In this fifth episode of the Meteor Monthly Wrap-Up, we cover a lot of ground on the open-source side, discuss the open position with Meteor Software, and much more!
We covered a lot of ground in February! On this episode of the Meteor Monthly Wrap-Up, Filipe and Matt discuss developments on the open-source side, including:
Meteor 2.1 (Node.js security release): Node.js released its update on Feb 23rd, and we released ours just the next day. A trend that we're hoping to continue, especially with security releases.
New Development Hire: Meteor Software is hiring! If you're a passionate Meteor developer that wants to contribute to Meteor and Meteor Cloud, we'd love to hear from you! Bonus points if you are already a Meteor contributor. See the full job description here.
We also dive into Verified Accounts on Atmosphere, Meteor Examples, the Meteor Job Board, and much more!
Thanks for listening!
Hey everybody, and welcome to another episode of the Meteor Monthly Wrap-Up. My name is Matt, and as always, Felipe is here with us. So let's go into what we were up to in the month of February, 2021. So on the open-source side, this is going to be open source heavy of an episode, here, we have a few updates on that side. We have already released a new version of Meteor, this is 2.1. So Felipe, what is important about this release, and what should people know about?
Yeah. We were not planning to have this released that fast, but Node.js released a security update and it was involved three type of security issues. And we decided it was important to release this as soon as possible. And it was pretty good, because Node.js released, I think, in 23 of February, and you released just in the next day. Then it was a very short time between these two release, what's good, because then you can keep your app protected.
And we decided to release these version without any other big change, because, as these are security updates, then it's better to just update without to be worry if you need to retest your app, or ... Of course it's good to test, because Node.js released security updates that could affect your application, but at least you don't need to worry about more features there that can break your app.
And also, we used this release to also include another change that was ready. That's the ability to send the plan when you deploy to Galaxy. Then, if you have a paid app, anyone to downgrade to free, you can do this. Of course you need to run just like one tiny container, and that's the restriction that you have for the free. But also if you want to upgrade, or if you need to change to professional, it's just to be easier for you to change the plans in the CLI, in the command line. Of course there are some rules for each case, but at least you have this ability, and that can be helpful for you to migrate easier to a new plan.
Sounds good. And we weren't planning on talking about this, but there were some mentions on the forum about the convention of the 2.1 versus 2.0.1 Was there a reason why we went with 2.1 there?
Yeah, there is even a discussion for one of the Node.js core members. I think somebody asked this probably about a different tool, and then he was answered like, "Yeah, I don't know if it makes sense or not, but in our case, it's like Node.js is our main tool in the backend, like Meteor is a Node.js framework. Then your app in production is running Node.js in the server. Then as Node.js has a minor version upgrade, then we decide to also follow Node.js, and also have a minor version upgrade, just to communicate better than, because one of the main components was suffering minor updates. That was the only reason to have that. Because usually the patch, third number in the firmware is more for bug fixes. And this is not really like just a bug fixes, it's like a security update, then it's an important one. That was why.
Sounds good. So those of you who are wondering, there you go, there's your answer. We are also going to try to keep updated as much as possible for these kinds of releases, so I was pretty happy that we were able to get this as soon as we were. But hopefully we'll be able to continue that and make these a speedy update when it comes to security releases from Node, especially. So that's that. Felipe, I was going to ask you about your progress with the new hire that we're trying to make here, and just quickly we can touch base on this. What is it that you're looking for specifically, and how is that going, and what should people do if they're interested in applying for this role?
Yeah, some guy was asking the forums, like how was the progress? Then I just went to explain a little bit the process here. Like, first to try to wait a little bit, to receive candidates and to receive the resumes. Don't want to rush a lot, because maybe people are now week of they can miss the process, then that's the important part. We are just waiting a little bit to receive the resumes, then you can talk to people. And the second very important part is that everybody that send us an email is going to receive an answer, in every case. Like, If you send any email to any major communication channel, you should receive an answer. If you're not receiving an answer, probably is because you're send to the wrong email, or because of our fault you are going to a inbox that's not there.
Then in any case, you should reach firstname.lastname@example.org, because you should receive an answer. Then we are going to reply to everybody. And it's not just going to be, "Oh, we received your email." We are going to try to understand what was your point, and try to reply. And that's the same for the hiring process. Because I know it's very frustrating when you candidate to our position and nobody replies back to you, at least, "Okay, this position is already closed." Then, in this case, of course, as we did the last time, we are going to reply to everybody, we are going to talk with people that we think are a good match.
And in terms of a good match, we are really looking for someone that is capable of improving Meteor in the open source side. Because in the private part of meter, like Galaxy, cloud, it's hard for you to be prepared, because you don't know what you are doing exactly because the code's private. Of course we are using Meteor where it's possible, but in the open source side we want people to contribute with new features for Meteor, like you have a big [inaudible 00:05:29] map, it will have a lot of feature requests. And that's the goal for this hiring, is to get someone to help us in this side especially.
Of course this guy or this girl is also going to learn the private parts of our code, but I think for the first tasks it's going to be in the open source side. Then if you like to contribute to Meteor using the pull requests, or if you have very cool ideas to add new features to the framework, you are the good candidate for us, and we'd like to talk to you. And we are going to talk to a few candidates. Already we have received some resumes, and that's going to be pretty soon, so be prepared.
Be prepared. And just so everybody's clear, does it affect how closely you look at a candidate if they've already contributed to Meteor, and this will improve your potential here for applying for this position, if you've already contributed in a meaningful way?
Yeah, it's not required to have public contributions because we know many guys that know a lot about Meteor, they are working private companies and they are really busy and they don't have time to do officers' work. But of course for us, it's better, and it's also easier to identify someone that already know the code, already know how it thinks in terms of open source, we can see how he interact with the community. And then, of course, for us it's like a shortcut. It's an easy way for us to analyze a candidate if he is active in the community.
And again, for this position, it would be very helpful if you could find someone that's very active with code contributions, and also checking the bugs, and checking if the issues are really an issue. All this work in the open source area is the parts that we are interested to hear.
Sounds good. And then that will be, is it the email@example.com for applications there?
No, we'll have a different email for the hiring process, it's careers, but it's in the position that was announced in the forums. Then I think everybody would be able to find. But if you send to hello, we are also going to check this. But it's better to send to the proper inbox, because I track this in a different way on my account, then you are sure that I'm going to get your email.
Sounds good. And we'll link to that as well in the show notes too, so anybody who was interested in that can find the right inbox as well. All right. So the next piece that I wanted to cover, and I think it would be relevant for the community, is the verified accounts for Atmosphere. And when I say verified accounts, these would be technically Meteor cloud accounts, although prior they were MDA accounts, or MDA media developer accounts. So a little bit confusing, even the naming convention, but can we talk a little bit about the verified accounts and those packages on Atmosphere?
What was the intention behind this idea, and I guess maybe more information for people?
Yep, sure. We are hearing the community, and one of the things that we have with Atmosphere that is pretty cool is that we have a lot of packages there, like 14,000 packages, I believe, today. But in the same way, we also have very old packages, because people are moving on, or they are changing their stack, or they are working different projects. Then, of course, some packages are going to be behind. And a nice way for you to understand if a package is good enough for your users is if you know who is behind it. Like, who is keeping this package up to date?
And then with verified accounts, that's our idea. We should put a flag in a few accounts that request this verification, and then we check the code quality. In some cases we don't even need to check, because we already know who is behind it. Then when they send an email, we just, "Okay, we know this guy, we know he's doing a great work," and then you just verify, because we already know. But if you are new, it's not a problem. You can just sending the same way, and we are going to verify our code, because maybe you're new and you don't know exactly who you are.
And then if you can verify, like your code is up to date, you fixing bugs, you are replying to PRs, to issues on GitHub, then we are going to have this verification in our account. And this is kind of the first feature in a series of features that we are planning to have in Atmosphere. We are going to talk with the community all the time, but this first feature, I think it was, well-recepted, received a few verifications requests already. And if you have a package and you we really want other people to use it, it's good to ask for your verification. Then the user can have the confidence that somebody checked this code.
And there is a special reason that this is in the account and not in the package, because they have a lot of organizations, they have a lot of packages. And it would be a lot of work to request individually for the packages. Then it's nice because usually when you have one package that is good, disorganization or this account has many good packages. And also we are working and we have an open PR already for deprecated packages. Then maybe you have like 10 packages that you are keeping up to date, but there is one that you want to deprecate it, we are also working a way that make these available on Atmosphere, and also available in the command line, so you can understand this package is deprecated. The storyteller, the community member is working this PR.
Then they are just nice ways for you to identify better, which package you should work on, or maybe you'll love a picture, use a package, but this package is not maintained anymore, then you can create the [inaudible 00:10:43] or you can ask for the alter to migrate to your account. Then this is the idea, to provide some visibility in the packages and how they are being maintained in the last months.
Sounds good. And for those people who want to have their account verified, should they just reach out to you with the same inbox, firstname.lastname@example.org?
Yeah, they can send to hello, but the best channel there is email@example.com, because then more people are going to have their eyes on these tickets, and they can verify you as fast as possible. And it's not just me, the whole core team can verify your packages and can add this flag to our account. Then that's the idea. Just send to firstname.lastname@example.org, and we can help you.
Sounds good. All right, so the next piece here on the open-source side is something that I believe you pushed out on the Slack community recently, and I just wanted to bring more visibility to it here in case people miss that. And that was the media examples repo. And you mentioned it was a good way to expose your projects and give [inaudible 00:11:41] a head start in existing media projects, and how packages are being used, and that sort of thing. Can you tell me a little bit about why you decided to revisit that, and how helpful it could be, and for what use case, and what's it for exactly?
Yeah, sure. I believe this is one of the most requested resource for people, because we are probably, if you're listening to this podcast, you are not start with Meteor, maybe you're using Meteor for a few years, and for us it's like, "Okay, Meteor is easy, you just do this, you just do that." But for us, because we are working with Meteor many years, it's easy. But for someone that is new Meteor is not like a just one choice framework. Meteor has multiple choice. Like, you can use blaze, you can use react, you can use angler. We are updating angler, with the community help, of course, then we are going to have some news on this soon. But anyway, it was just a segue way.
And then you can choose your UI layer. You can also choose your data layer, like you can use the graphical, or you can use [inaudible 00:12:42] or you can use DDP, of course. And then we have these options, but if you are new, you don't know the option, you don't know why DDP is better for this specific use case. You are just like, "I'm starting." And then you have two ways to address this. You can show a lot of [inaudible 00:12:58] with a lot of steps, or you can also show like, "Okay, this is an example." Then you can understand it and you can see, "Oh, I agree", "I don't agree," this is good, that's not good, or I should have start my project just using these as a starting point. And that's enough for you. Then that's the idea with examples.
And examples is not new in Meteor. What is new is that you moved the locations. You had examples before besides the main repo, but the main repo need to run a lot of steps, you need to do a lot of stuff to get your PR approved. And the examples are not running the tests, but you are just running because GitHub is just running all the checks all the time. And it's also a huge repo for you to check out, you have sub-modules, then it's a lot of work. Then it's better to just have a clean slate for us, you start to add in new examples, and you don't need to even add the examples in this repo. You can just add the links there.
And then we started with two examples. One is hosted inside the repo, the Meteor slash examples on GitHub, and the other one is not inside this repo, it's just linked to a different repo. There you can keep in the way that you prefer, but the idea here, like our plan is to review this at least six times in year, probably, and to make sure that it's really working. Like, they are working, they are up to date because maybe some major piece was changed, and example is not updated, then we are not going to allow that. We are going to keep these examples up to date, because otherwise they are useless and they can even cause more problems than benefits.
Then that's the whole point. And how you decide if your example is a good example or not? You don't need to decide. Just open up PR, or open an issue and discuss with us, with the community. Just open issue. "Oh, I would like to publish my example with SSR," and then you can discuss there, and you can decide if you want to publish or not. Then you don't need to think alone. You can think as a group, and we can decide what are good examples, what are bad examples. To be honest, I don't think there are bad examples. Maybe it's just bad If you have two examples that are using exactly the same thing in a very similar way, because they are going to be just duplicated, but besides that there is no bad examples. Any code running Meteor that's working, you should be sharing this code, because maybe you have another user that has the same use case.
That is like, you have your project, maybe, you can just delete a bunch of private stuff, and maybe you can publish as an example. That's also great. Then we just went to provide more resource for people that are starting. If you're a vetted advanced user, probably you don't want to use the examples. But you probably can share one example, then think about it, and you can just open issues. And again, the repo is Meteor slash examples on GitHub.
Sounds good. And we will link to that as well in the show notes too. And yeah, this is just part of our, just to reiterate, it's part of our process to get more people seeing the value of all the different components of Meteor. So it would be very helpful if you all contributed a use case, or if you saw something that might be helpful for new users. That's the whole idea. Bring more people to Meteor, get them exposed to how malleable it is, and we'll work together to make that happen.
And on that note, I did a small survey on the community last week asking about [Baylor 00:16:16] there. And I was expecting to see, of course, a lot of DDP, that's methods and publications, and also a few graphicals and also a few rests. But in general, almost everybody was using DDP, at least in the developers that are in the Slack community. I know it's just like a supergroup, it's not all Meteor developers, but that's one thing that the example can also presents, can also show, "Okay, here's how you use it with DDP." And maybe you're going to have, like, 10 examples with DDP, that shows, okay, DP is really strong. And I love DDP, for me it's the nicest part of feature, because it's very effective, and you can [inaudible 00:16:54] in many different ways.
And the example that I post there, that is a small app to mark the movies that you want to watch, and it's consuming a third-party API, and then you can just check the movies that you want to watch later. And it's very nice and it's very simple. I don't count the lines, but I believe it has less than 500 lines, probably. Then it's very small, but in the same way, it's working. The UI is not like the best way UI, but it's okay because I am a developer, I'm not a designer. But it's a nice UI. You can interact with it. It's also a PWA that you can use in your phone. Then it's a very nice implementation with a few lines of code. This was not going to be possible with graphical.
And I love graphical as well. I think it's a very nice idea, and it's a very nice implementation, like with Apollo, but it's very, very [inaudible 00:17:43]. Then in some cases I don't use graphical, I just use DDP. And that's the joy of the examples, you can compare. You can see real code. Maybe you should write the same example that I did for the movies using graphical, and post that, and you can compare. This is the idea with examples, just to explain a little bit more. Then you can understand how to use the components together.
So it sounds like it could be helpful for everybody, whether you're beginning, or intermediate, or even expert as well, just to see what the other side of the coin, if there's another argument for using a different component, or a different way of doing things with the Meteor. So don't limit it to just entry-level people using Meteor. It could be helpful for everybody, and that's the idea. All right, let's get into the next piece here. I just wanted to mention quickly that we do have a, again, as part of this whole pitch to bring more people to Meteor and to get more people using Meteor, and then therefore hopefully get a job using Meteor as well, there is a job board out there called WeWork Meteor, which is great, but we decided to spin up our own as well in tandem with that.
So we do have a Meteor job board, it is in the footer of our homepage, and we'll also link to it here. But again, trying to get companies to post there who are looking specifically for Meteor developers. And it is free to use, so we don't monetizing it or charging for use there. Since everybody knows, we're going to be filling that job board with more positions, hopefully, in the near future. I think it's got nine or ten there now, but in case you're wondering, for Meteor specific jobs, there is a job board on our site and it is in our footer.
On the job board, just to highlight for Meteor developers one more time in this close relationship with Node.js, Meteor has some special implementations, I would say, like with fibers. That's another topic for our discussion pretty soon. But we are Node developers as well. And then we know many Meteor positions, I just announced that there's no JS positions, because they are also correct. They are also Node developer positions. And then that's good to have the job board just for Meteor applications, that it's at least easier for the community to find these positions. Because for the companies, usually, Meteor is not hard to learn. Then usually for the company, it's just better to announce Node.js, even if they are using Meteor in all the projects. Then like it's a little bit bad for us, because it's hard for us to track down all the Meteor positions, but you know we have thousands of apps running on Meteor, and of course this company have developers.
But it's a little bit tricky for us to find the exact positions, because it's better for the company to announce Node.js, because they can teach Meteor pretty fast. And I know a lot of companies that are just announcing Node.js positions, but in the end they're using Meteor, because they can train people to use Meteor in a few days. Then, just to highlight this difference, but this job board is specific for Meteor, then if you really love Meteor, and I think probably a lot of you love Meteor, then you can go to a specific place and we also have other job boards for Meteor, but this one at least is in our homepage, then it's easier for the companies to find as well.
Yeah. I think if you're listening, if you've listened to us for 22 minutes now ramble about Meteor you probably love Meteor. All right. So let's continue on here. Felipe, I believe you had something you wanted to share here as well, or anything new down the pipeline here, so do you want to chat about that for a bit?
Yeah. We are wrapping up a few lines of work. One part, it's probably going to be new for most of the people that we are working on this, but we are working with zodern. Zodern is like a no-name name in the community. And then we are working with him in a new Meteor installer. The first focus is going to be on windows, because on windows today you need to install a few tools. You to store PowerShell, you need to install Chocolatey. And then we want to provide a better experience, probably just installing Node.js and NPM, and then you can install Meteor using NPM. That's our goal. And we are not far from that.
And we are also going to have the final versions of [inaudible 00:21:45] module replacement pretty soon. And we are also working more stuff, like in the core, we are working with the Node.js upgrade to the 14 version. It's a huge project because we need to test everything again, and you need to make sure all the tests are passing. And also we are working again on the [inaudible 00:22:03] pretty soon. Then we have a lot of things going on. You can see, like, we are 23 minutes here, talking about Meteor open-source site for the last month, but that's just for you to be prepared, like you are going to have this new installer, and the feedback would be very welcome.
We know Windows can be a little bit hard sometimes, and then if you test this and you find any issues, you please report to us. And we are going to probably first have a beta, and then later we can update the website and the instructions to install Meteor. But it's very important to have the participation. Like if you're a windows fan, if you are using Windows like every day, we really want your feedback about this new installer that's coming soon.
Sounds good. Okay, so we just talked about the open-source side for almost the entirety of the podcast. We'll touch base quickly on a few things with cloud before you wrap up. The first thing here we wanted to discuss was the updates to the logs, and the ability to now filter by range and download the logs as well. I believe you could download the last 10,000 lines, if that's correct, Felipe? Anything else on the logs update and functionality there that you wanted to touch base on?
No, I just wanted to highlight the range, because it looks like a basic feature, and I think it is, but we are just releasing now. But before, we could filter by a date, but it was just like [inaudible 00:23:20] date, then if you filter, like until one hour ago, then you'll just see the logs until an hour ago. And it makes sense, but with range it's a little bit easier, because usually you'll know better than just the final date.
Usually, you know, "Oh, I'm looking for an error," or you can use the search, and then you can click in the time, and it's going to already put the range for you close to that time. So a small addition, but I think it can make your life very easier. And if you don't want to use the search or if you are not finding the log that you expected, you can also click in the button there and you can provide the raw form of just text for you. And you can just search using your favorite tool to search.
And also another feature that logs, that maybe many of you don't know about it, you can also use your [inaudible 00:24:07] storage. If you don't want to have your storage on our site, you can also configure it in just one line in your settings, and you can send the logs to your Elasticsearch. Many clients use that because then they can integrate their last search with other tools that they have already in production. And then if you want that, it will have the docs there, it's called [inaudible 00:24:28] storage inside the logs dock in the guide. And check it out if that's a better option for you.
And also about the search and these new features, if you're having trouble using it, just please open a ticket, because maybe it's there, it's working, but it's not in the best way in the UI, then you are not understanding the feedback. Because when you have a lot of logs, it seems to be like a very easy task, but it's not. It's hard to understand sometimes, because we have a lot of logs in the same timestamp, then it can be tricky, but you can just open a ticket and you're going to try to explain, or even to fix if you find a problem there.
All right. So one more thing before we wrap up here with the cloud side, I thought it'd be a good idea, maybe we could do those ones depending on how many more minutes we go here, but to talk about a specific feature on cloud and within Galaxy specifically that users of Galaxy may not already know about. And so I decided to do the SEO optimization that comes as a part of the Meteor cloud and using Galaxy specifically for hosting via pre-render, Felipe, do you mind discussing this quickly? I wanted to make sure people were aware of it, and there are other solutions [inaudible 00:25:37] that you might be able to use, but with this comes pre-packaged within Galaxy and you're hosting with us, so can you discuss on the pre-render side?
And it's great. We have many applications using it. I think basically every application, Galaxy is using pre-rendering and you can have your page ready for a search, and that's it. That is not much to explain because it's a very effective feature, but it's very easy to use. Just need to have your site ready, and you also have the documentation about it, you have a special URL that you can put there to see what is the result. If you are a search, then you can simulate, and you can fix it, because maybe you are providing the wrong content for search. And that's it.
All right. Just a fun thing that not many people know about I don't think, so I wanted to highlight that within Galaxy, and yeah, well, let's wrap up for this February, where there's a lot we discussed, and mostly it was on the open source side. Felipe, anything else you want to discuss before we wrap up today?
Nope. Thank you guys.
All right. Thanks all.