@orafaelfragoso
Software Engineer | Full-time Dad | JavaScript Enthusiast | Entrepreneur
Always curious, I began my study of the web and other technologies when I was 13 years old. I also love the psychology field and how it fits perfectly into creating products.
I’m always looking to use the new market trends, and, to keep me updated, I give speeches, write blog on subjects I’m studying, attend to conferences and I’m always trying to teach what I learn.
I also have another blog called Nômade na Web, where I write about working remotely, digital nomads, life experience and productivity.
Work and business proposals
No blogs yet.
Only go in-house if you are handling lots of files and doing lots of operations. And also, if you're looking to scale. But do have in mind that you're gonna need an investment. So, always go third party, specially in 1.0. It's simple. Take a look at this project if you're thinking in in-house in the future: https://github.com/thumbor/thumbor
You can get very confused coming from a PHP world to JavaScript, mostly because you can write JS everywhere. I believe you can master it by taking a step back and understanding what's going on in the first place. With JavaScript you can work with many architectures, this is why is so good. Here's a few examples: You can have an API written with NodeJS and another React application running on the front-end. You will end up with 2 servers or 2 processes running in 1 server. You can also have a monolith, which I believe you are already used to it. When you run both your interface and logic + database in one application. So you will end up with 1 server. You can also have an Isomorphic (Universal) application, where you combine the power of front-end and the rendering of the back-end (It's possible with JavaScript, since it's the same language). With this you can even choose if you want to separate the API into a different application or write the logic into the same app. And which way you decide to architecture your application, every time you use a scaffold tool like create-react-app etc. You will end up running a server to start your application, because it's way more convenient when developing. But it's totally doable developing the old way, importing everything on the header of your HTML etc. But when you finish developing and building your application, on the front end, these tools will generate an index file and all the final boilerplate for you, so it can be as simple as copying to a FTP server and checking your domain. But if you build a NodeJS application, you will need a server, like Apache or Nginx, the same way you run your PHP code. JavaScript is a really powerful programming language, and it is so flexible that it can get really messy. But the bottom line is: You have to learn about application architecture. I really recommend you taking a course from basic to advanced to better understand this. Here's one: https://www.udemy.com/the-web-developer-bootcamp/
As creators (developers) we are responsible to test our code, writing tests for the application, giving the user the best experience possible and protecting their personal data. More valuable than the money we earn, is the time the user spends on our apps. It's a time they won't get back. So our code needs to be translated into those responsibilities. So I recommend some reading on: Data Structures Design Patterns TDD and BDD Web Security
Usually, when you have the app on a subdomain, that's a whole other app. The subdomain points to a different ip address where the app is deployed. That's a good solution because you can work on SEO on your landing page and have a PWA on a different place that don't necessarily need indexing or SEO.
Lee Watkins - Follow me on twitter and send me an email (rafaelfragosom@gmail.com) and I'll call you when I start this project. It must be doable in a week and we can improve it later, because I have 9+ projects so far.
I'm adding to the list. I've been playing around with Github's API for a couple of weeks and I will see if that's possible. Thank you!