cyberpanther

This is why if Apple ever did a legitimate server offering with virtualization they would kill it. How many devs, develop on Mac and deploy to linux? And also now use VMs for containers. Imagine if MacOS supported containers natively. They leave so much money on the table.

I really hate this meme because it misunderstands how learning takes place.

If you are learning basketball and only did the fundamentals you would be practicing drills your whole life. Drills are important but don't teach you everything you need to know. You need to practice the fundamentals in the context of a game or you will not get good.

Learning frameworks can definitely be detrimental too but for a beginner, a framework is often a real world example of how some fundamentals work. Einstein said "Learning is an experience. Everything else is just information." Learning fundamentals is just information. Practicing them in a real life situation is learning.

So I like to learn new frameworks to figure out how principals I've never used before work. Sometimes I'll continue using the framework and sometimes I don't. I think it is definitely prudent to limit how many frameworks you learn but it is wrong to throw them out totally.

pipenv is not perfect but it is definitely headed in the right direction. It is a lot easier for beginners to get started with which is one of the best things I've found.

To address one of the problems, Running Scripts: basic complaint is you are starting a new shell always and you have to prefix all commands.

Prefixing commands sucks but you can get around it pretty easy with an alias.

alias pr="pipenv run" alias dm="pipenv run python manage.py"

now 'pipenv run python manage.py startapp foobanizer'

becomes 'dm startapp foobanizer'

or 'pr django-admin startapp foobanizer'

As for the shells. I really like this feature because it's a lot cleaner. With activate and deactivate you are essentially mutating the current shell which can be dangerous. Also because it loads your ENVs on every run, it's easier to switch out ENVs.

This is also a problem with developer bootcamps since they get a lot of "sales" from reviews. They can often cater to students to the detriment of the learning experience. At times it is about catering to creature comforts, but can bleed over into lessening the learning experience.

And especially in bootcamps since things are so fast paced and often times emotional, the reviews are not objective. Many are too positive or too negative.

I think the problem with heroku is not scaling but the cost. They use AWS behind the scenes so you are paying a premium over AWS. Eventually that will become expensive. But if you are saving money on labor it's worth it.

I would love to get rid of www but this going to confuse the heck out of people. We could get rid of www if more DNS providers supported ANAME. And Google Domains does not. How bout start there.

You can use Termux on a Chromebook to run Linux already and develop. See termux.com and https://medium.com/digitalcrafts/exiting-vim-on-a-touch-scre...

This is without going into dev too. You just need to enable android on your chromebook.

OK for real. :-)

I've always liked Python for web dev because it is a good general purpose language, it's elegant, and has good web frameworks. Some other languages are really good at the web but not much useful outside of that. So with Python if you are building something with data analytics and the web it's a perfect choice. Python pairs well with a lot of areas. It doesn't pair with everything well, such as, Javascript I think pairs better with robotics. And there are other good general purpose languages too (Javascript, Java, etc).

because of reasons

A good analogy is a bootcamp is like a personal trainer. Sure you could do jumping jacks yourself but when someone yells at you to get them done, you do it more often and faster. Some people need that extra push through.

But yes some people have plenty of self motivation and can do it themselves. The career networking is really all they need then.

Oh yeah watch out for bootcamps that juice their placement stats by hiring their own grads a lot. It's normal to hire a few grads for teaching assistants but if you see more than that be weary.

If you look at long term value, the tuition is really nothing. At a good bootcamp even without any industry contacts you will probably have a job in 6 months. Sure your salary will be lower than a CS grad, but you'll also have way less debt.

But yes look at placement rates at any bootcamp before joining. If people are getting jobs then it's well worth it.

I would say in addition to Intern -> Developer -> Senior/Lead where Lead is Org and management skills you need a Senior/Expert path too.

Some devs will never want any management duties and you shouldn't give it to them. However, they then probably are going to be a master or have really deep knowledge in something valuable to the company.

totally agree.

I would say a good 10-20% do have some kind of contact in the industry though and get a job that way.

I teach at a Bootcamp and see a lot junior developers looking for jobs. Many of them complain of it being hard to find jobs and it is. But I don’t think it is any harder than say 10 years ago when I got started. The main the problem is they’ve never interviewed for a technical position before or aren’t looking in the right places for jobs. Also a lot of jobs are perfectly suited for juniors but it doesn’t reflect that in the job description. So there are a lot of things that make the job search hard and frustrating but the jobs are out there. And I would love to see more companies more actively mentor people too. But those companies do exist today. It’s just a numbers game. If you can hold out, you’ll find it.

Two words: remote work

yeah but the oompa loompas keep you entertained with song and dance too.

The problem is most people get abstractions wrong. Abstracting too much can lead to Architecture Astronauts. (https://www.joelonsoftware.com/2001/04/21/dont-let-architect...) And not abstracting enough can be a mess in your code and make a product dull.

By focusing too much on abstraction, you’ll get a really lopsided team. And remember it only took one really abstract thinking Willy Wonka and a bunch of oompa loompas to make really great candy. Too many Willy Wonkas and nothing would ever get done.

Lastly, most people only get abstractions right with experience. So there is still some value in experience.

One of the organizational problems I've seen with ENVs are when there are too many of them. When someone starts up a new environment for staging or production, they just copy all the ENVs from another environment and don't bother going through each one to see if it is valid or safe to copy. So you end up with a testing environment that can send real money. What fun! Been there!

This can happen with configuration in code too but at least it gets checked in and there is usually a better review process.

So I usually go for a hybrid approach. Have most configurations committed and tracked in code in different files, one for development, production, etc. This makes it really clear which configurations are more important. Any configurations that can't be committed to code, use ENVs or a secure key store if you can handle the extra process complexity.

This approach can still have holes but at least the surface area is reduced.

I always find it good to make developers feel the pain of customer support. Feeling this pain usually improves your product.

send me a DM on twitter https://twitter.com/pizzapanther

Totally understood. Part of adding a quiz allows you enter multiple accepted answers. And quiz quality depends on the person who entered the quiz. The intention is not for us to come up with curriculum for everything but for people to come up with their own quizzes which they can distribute to a class.

However, that particular quiz is one of our "launch" quizzes, so I went ahead and added that answer. Both chemistry and organic chemistry should work now.

I'm guessing you started in voice mode and then went to text so your mic is overwriting your text. If you stop the mic or use the text button, it shouldn't do that.

Definitely, lots more planned. This is just the launch product. I've been thinking of integrating other platforms like Amazon Alexa. Also embeddable and APIs would be possible. Let me know your use case. You could actually hack the API now since its a SPA architecture with a GraphQL API.

As for the stack the frontend is VueJS and Vue Material. The backend is Python, Django, Postgres, Elastic Search and some Redis spread in for caching.

Its running on pretty limited resources right now, but I'll scale it up when I get some traction. So if it's a little slow sorry not sorry, but it seems to be holding up pretty good for using mostly free resources.

> No other optimization will come close to the benefits of server rendering.

"Only the Sith deal in absolutes", Obi-Wan Kenobi

Valid point. In addition to technical optimizations besides SSR, you can make perceived improvements too. If you get a first initial paint in one second lets says, you're not going to hurt engagement. There are plenty of tricks you can pull out first before you need SSR.

Sure if you're using Node.js pull out SSR first since its easier. But for Python right now, it's not the easiest thing.

I usually ignore server side rendering or isomorphic rendering. I'm not saying all projects should ignore it but you're really talking about a high level of optimization if you need it. And if you're reaching that level of optimization you probably shouldn't use Python.

Server side rendering only makes the first view faster. After that, everything is rendered on the client and faster that way. And if you use caching with progressive web apps or just file caching in general, the first view will be fast after. So you're only optimizing for the first of the first. You can then provide the initial data in the page request so that saves a round trip on the first request while still rendering on the frontend.

I say all this to just point out that there are many ways to speed up your frontend without doing SSR and they are much easier to implement with Python. So I'd rather exhaust all these techniques before implementing SSR. If I get to that point though, I suspect Python might be the slowest part of your stack. And lastly if you are doing SSR for SEO purposes then just use a prebuilt prerender service.

With all that said if there was an easier way to SSR with Python/Django, I'd definitely use it. But Jinja on the frontend doesn't sound like that answer.

Sometimes lowering your expectations are a good thing for everyone. Now we know the pros and cons and can use it appropriately. No one particular habit is going to solve all your problems.

https://www.youtube.com/watch?v=7gt4StirOzc

I have a wide screen and don't use it multi-tasking but more to stop switching so much. My web development setup. One third code and terminal, one third the app i'm developing open and one third design or requirement docs.

Yes its harder to manage windows but once its setup, I don't find that i'm fooling with windows all day, just a minute whenever I restart my computer which isn't that often.

Why are startups obsessed with subscriptions? Just sell me some coffee. Start an Amazon store and let them handle the logistics.