bpatrianakos

I think this only applies to people implementing their apps using SOA as pat of cargo cult thinking like was mentioned in the article.

I ran a company with 4 employees. 3 developers and an idiot sales guy. SOA made perfect sense from the start. We had daemons running background tasks on our servers in Go (the best tool for that job), a separate data API we used for our main "monolithic" web app, and then our mobile and other clients all used the data API.

The developers working on the web app only had to know the API end points to get data into the "monolith" and the rest of us working on the API and daemons understood how all the other clients would use them. No issue.

I'm all about the idea that you shouldn't implement an SOA because successful companies do it but I feel like this article is recommending building a monolithic rails app or something as a reaction to how popular and talked about SOA architecture has been lately and doesn't really leave much room for the idea that small companies (even really really small ones) can use it and would it would make sense for them.

I couldn't agree more about the mass market being morons. It's hard to say and not often said so bluntly in public though. Not because it's untrue but because the person saying it could be afraid they might be a part of that group of morons. I can't tell you how many times I've heard a moron call everyone else morons. So is there ever any way to know when "the mass market are morons" means what it says literally or when it's a stand-in for "most people aren't agreeing with my strongly held beliefs".

I don't see a need for the snark. I don't see this as a troll question at all. Python is obviously thriving for scientific programming but it's not hard to tell that the question being asked is about whether Python is losing popularity as a general purpose web programming language.

If someone wanted to get into building web apps would Python be a good choice?

The answer is likely to be colored by your experience. I'd say yes, it is losing ground to other languages in the context of programming for the web. The people who use it know why they're using it. Othetwise you don't see many coding boot camps teaching Python. It's all about Ruby and Node.

But is Python dying? Not by a long shot. It's just getting less attention right now because of some of the other new toys that are making a lot of noise right now.

But this is specifically marketed toward developers and designers. So my question is are there really enough of those developers and designers interested in a WYSIWYG took or would it be better to drop the Bootstrap focus and focus on the small business owners and content creators?

Is there a big market for WYSIWYG apps for developers? I think this is a great application but might it be better targeted toward non-technical people? Remember iWeb? This reminds me of a more developer-centric, flexible version of that. But no developer would actually build with it. It was for the people who now use Wix, Weebly, and Squarespace for their websites.

Developers should be able to put together a Bootstrap front end just as easily in code and probably prefer working in code.

Maybe there's a huge developer market for this and I just happen to not know anyone who'd be into this.

I'd argue the barrier is just as high. I taught a ten week course in back end development and I think the students would have done equally well deploying on a VPS or Heroku.

The curriculum called for using Heroku but I regret following it now. Heroku bills itself as being easy for a beginner but go ahead and try to deploy any simple Rails or Node project using their guides. Half the time something goes wrong. Either you need extra dependencies or you have to do extra configuration that the setup instructions didn't mention. In the end you have to look up how to check the logs and even if you get that far a beginner has no clue what those logs are really saying. Even as an experienced senior developer, I couldn't get the demo project I was showing them deployed without a ton of hassle and 4 attempts.

So while it may seem like a VPS has a lot more moving parts, it's a better deal overall. Same level of confusion and complexity for students but in the end they at least know a bit about how a server works (which Heroku hides) and it's way cheaper even with SSL. I could have run that same project for $30 up front and $10 monthly.

I think it sums up the Beginner Community in general, not the JS community. You see this with beginners in everything.

No SQLite isn't heavy but I hope you mean for use in development only.

The issue isn't MongoDB is bad and relational DBs are awesome. The real issue is new developers being taught that Mongo and NoSQL in general are the databases you should be using with Node. The problem secondary to that is devs not knowing when each is appropriate.

This is great but it really only applies to SPAs. I know single pagers are all the rage these days but it often makes a lot of sense to structure your application in a hybrid way where you have full page reloads for different sections of a site and each section is a container for a different SPA. I've got a decent setup for this but I'll be damned if I can find anyone who shares their setup for this sort of use case.

CSS is not a programming language. You can't think about it the same way you'd think about your backend code or even client side JS. The global namespace is by design. It's a feature, not a bug. The whole point is to think about the Cascade. You go from vague to specific and that way you have entire classes of elements with base styles and specific components have additional styles attached.

CSS modules is a cool idea but I don't think there's anything wrong with CSS as it stands today. When you work in any language you need to understand and work with the language you have and I think that a lot of criticism of CSS boils down to "CSS doesn't work like this other language/paradigm I know and like".

These are all great ideas. The only thing I don't like about these types of projects/guidelines is the almost religious, strict adherence to them that some people who pick them up like to rant about.

The examples are great and realistic but they will inevitably break down in any project with just a moderate amount of complexity. When this happens I see people decide that they've done something wrong and think they either need to restructure the UI to fit the guidelines or find a different set of guidelines to fit their project. Both are wrong.

After years of studying these guidelines and trying to perfect the perfect, most efficient, small, and understandable set of CSS styles I've come to the realization that we need to simply accept that there are going to be exceptions and that's okay. Yes, think in components, give classes sane names, don't use ID attributes, etc. but also know that at some point you're probably going to have to break a rule and it's not the end of the world. Think about the problem for a few minutes but don't waste your time trying to shoehorn your front end code to fit a set of guidelines so you can feel superior because of your strict adherence to RCSS or SUITCSS or whatever. There are more pressing issues than a few unused or single use classes. If you can follow the rules more than 80% of the time then I say you're as close to perfect as you'll ever be. Anything else is reaching for an impossible standard.

It's funny that the stricter you adhere to some of these guidelines the less productive you become as you spend more time thinking about how to create components so they fit the rules rather than getting the damn styles to look however you want.

My point being this: I love all the different philosophies and think they're all worth studying but let's be realistic when it comes time to implement stuff.

They won't do it on their own because there's really no incentive to make this information easily accessible. Healthcare is like Microsoft and Oracle in the 90's. Everyone wants you locked in to their platforms and services. Add to that the fact that you're constantly dealing with incredibly sensitive information on the level of financial data (arguably even more sensitive) and it gets worse. In finance you have PCI compliance to deal with. It's tough but not as crazy as $50k fines for every instance of leaked data with HIPAA.

Having done exactly this type of integration with legacy systems I think a point that gets glossed over is that it's the startups themselves who are full of engineers who think that the whole world has moved on to using NoSQL Node.js RESTful JSON APIs in the cloud (that buzzword soup was intentional) when the reality is that the majority of established businesses are using unsexy and what they would consider to be "legacy" technology.

So you have companies like one I was recently a part of integrating a Node web app and API with SOAP and SAML end points and suddenly it's everyone else's fault that things are hard when really you probably should have thought through those tech stack choices before you started.

I'm not saying the article is wrong. I agree with it wholeheartedly but there's a lot to be said for not researching the market you're about to jump into thoroughly enough before you begin.

I disagree. I can relate to application setup and deployment feeling like its a fragile, error prone process but library usage in general is a good thing. Now if you're picking up obscure, poorly maintained libraries from GitHub I can see that going south quickly but as long as you're smart about not only which dependencies to choose from whom but also knowing when you really need them then you end up with a robust, easy to maintain system in the end.

The whole point of having a dependency chain is to benefit from well tested code that often does mundane things that you neither have the time or expertise to create yourself. I've found that as long as I choose libraries that are up to date, look to be maintained, are decently tested, and do something that I couldn't do as well or don't have the time to implement as well then all is well. I also have a rule that if a dependency is at all mission critical or not easily replaced I will either fork that library and maintain my own copy or create one for myself.

This has been true for every language I've worked with. Go, PHP, Node, or Ruby so far.

Updating might be cumbersome but if you're following best practices then you've got tests that ensure updating a library won't break your code. You also don't go around mass updating things. You update when there's a good reason to (security patches, language compatibility, etc.). Deployment should only suck the first time. Nowadays we have tools to ensure systems are replicable so you can be confident code will run fine regardless of the environment.

I don't think we'll ever have a plug and play experience. We have so many hobbyist libraries precisely because our languages and tools are so flexible. Hiding complexity is what programmers do for users. To hide from developers too would likely do more harm than good and result in a generation of programmers who don't understand how their systems really work. I point to Rails and Meteor as examples. There are Rails developers who are a thing in and of themselves. They're not Ruby devs who know Rails, they're just Rails developers. There needs to be the person like the Rails core team who know how to put dependencies together in a way that creates a functional modular system.

I don't see the benefit. It seems no easier on the eyes than JSON and it's more complex with more syntax rules to learn. I wouldn't recommend this for either humans or machines. HJSON would be my choice for a human readable data notation format.

Haven't tried it. I don't think I would as its a SASS project and I prefer LESS. My initial thought just upon glancing the readme was that it seems a bit bloated. Starts out with some great options then it looks like they've defined variables for every system don't imaginable. I like typebase because it's a very complete base that you can customize and build on without having to tear apart. Typographic seems more framework-y which is a turnoff for me.

But that's just a first impression and my needs and preferences aren't everyone else's.

I've been using this as the basis for my typographic styles for maybe a year now. My only problem with it has been the spacing between paragraphs and headings. I find myself using the .hug class a lot.

Most people don't disable JavaScript but beyond that edge case (I consider JS disabled an edge case) I agree that this architecture isn't necessary and overused. A single page app is great on a MacBook Pro with 2 tabs open but run that on most "normal" people's machines and it gets laggy quick.

People always mention disabled JS and SEO as pitfalls but I think performance and practicality are the obvious reasons not to do this that get overlooked. SPA architecture is something I use alongside server rendered pages. When you have one page or a series of pages in a particular user flow that would benefit from no page reloads and are heavy on interactivity then it makes sense but otherwise I can't see the value. I think developers will realize this and take a more balanced approached with a practical mix of pages rendered server side and pages that use XHR and JavaScript to enhance the experience.

Great suggestions for non-technical people in there but if a real concern is ownership and control of content then the only real option is buying or renting server space and putting up a website with maybe Ghost (the most overrated blogging platform ever) or the open source Wordpress or just plain HTML. All the other options listed still could potentially shut you down for some weird TOS violation (like if you're a big KKK supporter or something). Is it likely to happen? No. But isn't this where we post our overanyzed takes on everything?

The process is the same for those with sleep apnea who aren't overweight. Like me. I weigh 155 and an 6' tall. Born with a small airway and just got lucky it seems. So if your point is that if people just lost some weight they wouldn't have anything to complain about then I'm not sure weight is even relevant here. It's a very lengthy and time consuming process regardless of the cause.

Is there no alternative that saves users' data? Of course there is. But you probably don't want to put anything sensitive into any of them. There's no shortage of bare bones Evernote type services out there. I've been running one for three years without a single user losing data. They tend to forget their usernames and passwords a lot but never the data. (Link in profile, won't plug it here).

I still use Evernote for things I needed to store a long time ago and never ported anywhere else. It boggles that mind that the very core of such a service, writing and reading data from some store, takes a backseat to all the other buttons and gadgets they wrap around it.

> Developers shouldn't have to sacrifice their rights to speak and innovate freely just to bring their applications to millions of Apple users.

Ummm... Is this really why they develop for iOS or are they just having fun mostly, enjoying their craft and (sometimes) making a small profit on the side. The App Store is but one way to get apps. Sounds like developers with the beliefs the EFF attributes to them would be better suited to developing for Jailbroken phones.

I doubt and don't think they should feel threatened. If I were them I wouldnt be guarding my application because it's a very simple and easy to replicate concept. The real value is in the service. You pay for StatusPage because you expect they'll have better uptime than you and they allow you to focus on building your app and communicating with your customers. They take the work of building and maintaining a status page away. Pingdom is very similar. Something you could definitely build yourself but why bother when you have better things to do with your time.

Great! Now I'll just have to get a Statuspage.io subscription to watch my catchet install. But seriously, this is cool. Creating a StatusPage-type app has actually been on my todo list and even though I've moved away from PHP I think the fact that it's built on it makes its appeal and potential for use very broad.

My first thought though was "what happens if my Catchet instance goes down"? After thinking about it for a minute I don't think this should be a big concern for most. Assuming you run Cachet on a server separate from the one you're monitoring then the chances of both going down at once are small save for instances where you put both the Cachet instance and the app you're monitoring on the same provider like a Linode or DigitalOcean and they have an outage. Then I thought you could just get a free Pingdom account and have it ping your Cachet instance every few minutes. This way you know your status page is online (which is really all you need to know about a status page) and then the status page will give you a more detailed overview of the app you're really concerned about.

Great job, thank you for making this. I'm definitely going to use it.

So are you saying you try before you buy? The concept is sound but it falls apart the moment you get something free. How likely is it that after pirating a movie or an album someone goes back and buys it so they can vote with their wallet? I think pirating can be voting just the same except you're hurting the creator or distributors ability to make or distribute more of it. I Don't think that this is about whether something is worth paying for. It's about whether it's worth consuming. You wouldn't go to a restaurant, order a dish, then only pay if you think the meal was worth paying for. The meal has already been made, the effort to cook it was expended, and if enough people get their meals for free the restaurant goes out of business. It didn't go out of business because it made bad food necessarily, it only shuts down because their patrons were the type of people who thought it was okay to not pay based on their arbitrary standards of what's worth paying for. After all, by consuming the meal they've already implicitly voted that the meals were worth eating. Just not paying for.

It's great to see I'm not the only person who thinks this way. There are going to be no shortage of thin analogies and excuses in response to you in afraid. Regardless of the merits of copyright and how "dumb" the laws enforcing it are, I can't see how you can argue with your point about the content creators being deprived of an income. Maybe those creators do get screwed but they're still getting something and to say pirating is okay because maybe the system changes and those creators get a bigger piece of the pie or change their business model seems wrong to me. Who are we to decide what amount of collateral damage is acceptable? Like you said, this stuff is easily accessible legally.

Just about all of us can easily get what's primarily being distributed on sites like Pirate Bay. Netflix, Hulu, iTunes, Cable Company X On-Demand streams, HBO Go, Spotify, etc. it's all out there and far easier to access than hopefully getting a high quality rip off a torrent site. Okay, maybe some things aren't available in all countries and maybe the business model makes it next to impossible to buy a copy of a movie or song once and have it on all your devices in some cases. But really, is that really the primary use case for the Pirate Bay? Someone is going to say it is for them but if you believe that that's the primary use case across the board then you've got to be an apologist or just lying to yourself. Have I pirated movies, music, and software? Absolutely. Because I couldn't afford or just didn't want to pay for it. But I sure as hell am not telling myself that it was okay because copyright is evil and because "business models" and people who pirate wouldn't pay anyway so no one loses money. I live in the real world, not the ideal world.

Yes! I have 4 sites that I bought an SSL certificate for out of around 20 that run. If browsers wouldn't throw a warning for self-signed certificates every last one of my sites would have been secured from the start, easy. The only thing separating a self signed cert from one obtained from a CA is that the CA has some of your contact info but even then it wouldn't take a whole lot of effort to bypass their checks.

A speaker icon isn't making a judgement as to whether that sound is good or bad. Turning no-ssl into a warning is like having the browser judge you for being poor or cheap or incompetent. Not having HTTPS does not mean that you are insecure, it means the site isn't encrypted. There's a difference. Whether the lack of SSL makes you vulnerable to shenanigans depends on a lot of factors having nothing to do with SSL encryption and everything to do with the site content and what one may gain from snooping on your request or manipulating the response. Sometimes there's nothing to gain there.

I get your point but you're kind of blowing it out of proportion. A lot of people like myself host really mundane content and that concern is really the last thing on the minds of those types of site owners and their users. You want HTTPS when it's critical that no one manipulate the request and response but for most of us it's not worth the expense and effort. You want SSL on WebMD, Healthcare.gov, your bank website, and those political sites you read when no one is around but if some extra tracking get inserted into the response body of our favorite cat picture site then I think only you and I will notice or care.

SSL everywhere isn't yet practical only due to the expense. It's not that much more effort to secure a site but when you run 10 sites then you're spending $100 a year for those domains. The expense of an SSL certificate each on top of that makes it impractical for solo "webmasters" to secure all their sites. We all know why we should use HTTPS and we do it when it makes sense but it's just not practical 100% of the time yet. Like others have said, this will make more sense once the EFF initiative starts being adopted and getting a free certificate is as easy as apt-get secure-me-please.

Depends on your definition of addiction. Addiction is a real medical disease. To be addicted in the medical sense you have to a) have a dependence on the object of your addiction (your body has a negative response when you don't get the thing you're addicted to) and b) it changes your behavior and causes extreme negative consequences in your life. Things like Internet addiction only account for one half of that. I think that if the statement "you can be addicted to anything" can be true then either the definition of addiction your using is too broad or it needs redefining.