Nothing here yet.
Nothing here yet.
No blogs yet.
You should define the states for your component e.g. "loading, error etc." So when you api call is failed or still loading you may use those props to do some conditional rendering . So, if you are using Redux, just define some flags in your reducers for error and loading states, then check those in your JSX conditionally. You may also define an initial state for your reducer if you don't want null conditions for your objects (You can also use defaultProps but keeping all of them in redux is better IMO.) Note: You can return "null" from a JSX block if you don't want to render that part.
I like this approach; $tablet-width: 768 px; $desktop-width: 1024 px; @mixin tablet { @media (min-width: #{$tablet-width}) and (max-width: #{$desktop-width - 1px}) { @content; } } @mixin desktop { @media (min-width: #{$desktop-width}) { @content; } } p { font-size: 16 px; @include tablet { font-size: 18 px; } @include desktop { font-size: 20 px; } } It is easier to read but one down side is it can increase the file size. Here is the detailed post; https://davidwalsh.name/write-media-queries-sass
Those are from my bookmarks named REST API Design: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api http://blog.mwaysolutions.com/2014/06/05/10-best-practices-for-better-restful-api/ https://github.com/WhiteHouse/api-standards https://scotch.io/bar-talk/designing-a-restful-web-api There are also 2 awesome lists on GitHub if you missed them: https://github.com/Kikobeats/awesome-api https://github.com/marmelab/awesome-rest
Hello Mike, I mostly agree with you, modern web development is very sophisticated these days and web developer is a type of software engineer. But when I take a look at job listings, I believe companies are the ones that tries to distinguish those titles. But they are just titles made up by humans at the end of the day.
I don't think that speed is the first reason. I think startups using the dynamically typed languages are using them because the first developers are familiar with them. A team that are familiar with Java can code at same speed as Python developers (Java can be longer but it just typing, coding is not plain typing.) Of course there are advantages and disadvantages, but if you are starting from scratch and if you don't know if it will scale or not, it doesn't matter that much. Just go on with the one that you know. That's what Quora founders did.
You are right, but it takes time to have right decisions about "containers" vs "components" when you first start implementing Redux. Sometimes you can't foresee that a component should really be a container. (I've experienced a similar confusion about using component state vs. redux state, but i am more clear these days.) So, people have to be patient before deciding what sucks or not. Redux totally not sucks.
I think a web developer is someone who builds web pages for companies or some media agencies using Wordpress, e-commerce solutions or things like that. Mostly faces with problems that are already solved and implements that solutions taken from others. On the other hand, a software engineer is someone who designs and implements unique software and thinks about maintenance, code quality, testing, scaling etc. Mostly faces with problems that are not already solved or needs optimization. Companies like Google and Facebook needs software developers more than web developers since they are pioneers in most web technologies and mostly their engineers will be the ones that faces with unsolved problems.
Below are the examples I can think of about how a programmer and a non programmer brain differentiates; First of all, a programmer brain should always think the worst cases and possibilities that other brains wouldn't think about. Ask a group of people about how to make a peanut butter and jelly sandwich and you'll point the programmer brain right away. It is about exceptions. You both have to see the whole picture and also think every little detail that can be go wrong. Secondly, if you have a passion for programming, you could easily get obsessed with your code. For instance, if I had a bug that day or a design problem I couldn't find a final solution yet, the last thing I will think before sleeping will be that. I just can't take it off from my head; 'How can I make it better?', 'How could I prevent that happening again?' etc. (Of course my wife hates that because this is not a good topic for a pillow talk.) Many times I've experienced an enlightenment that the solution just formed in my head. I am not sure if I did sleep or awake. But I'd know what to do about the problem when I wake up in the morning. This is something comes with the obsession I believe. Lastly, I remember when I was a child it was more important 'how stuff works' other than 'what it does'. That's why I've disassembled every electronic or mechanic toy I had during my childhood. When I find out computer games, I've thought about how do those things work after playing a few hours. I am just curious about it. Many millions of people don't even think how a cell phone works. Voice transferred over air? It is just like a miracle. But a programmer brain is curious, he/she thinks about internals. He/She even have empathy with the other engineers built those things. For example, I can easily find out how a setting is changed on any consumer electronics without checking the user guide because I can see the device from eyes of the engineers designed it; 'that setting should be there'. There are many other differences, mostly originated because of programmer brain is more inclined to analytical thinking. And I believe most of them aren't related with talent but comes with experience and passion.