For my own understanding, why do you say "(Exceptions) turn your program from a simple local thing into a complex nonlocal thing, which is not a good idea if you want to understand it well."?
My understanding exceptions only bubble up if they weren't handled at the point of failure. This is exactly the same if you don't check the return type of a function that could return error. Both of this situations point to poor programming technique rather than underlying implementation option.
One thing that makes me currently prefer exceptions to error returns is that within a try/with block you can write the code as you'd like to happen and hence easier to understand and maintain. All exception handling can happen within the respective catch blocks.
I think one of the biggest reasons why most libraries/frameworks/apps/etc. use inheritance over composition is the easy with which the underlying languages allow the use of inheritance as opposed to composition. Most of these software writers know SOLID and other OO principles but when they're faced with the actual implementation, inheritance is just too damned easy to implement.
My problem with this approach is most people don't/can't pull it off properly with the end result being mediocre/sub-standard in either case. It's like when iPhone competitors tried to compete by producing duo keyboard/touch screen phones. They just ended up loosing both ways.
Pick one and do the best design/implementation you can pull off. One design/implementation is hard enough and unless you don't plan to do any real hustling (like getting out of the office and do some face-to-face marketing and lead generation), SEO shouldn't be that high on your list anyway. Good if SEO works for you but it's not the end of the world if it doesn't.
Correct me if I'm wrong, but I think most developers were "disappointed" with the "goto fail" because it was code structure issue which could and should have been caught at compile time. Hence the conspiracy theories because Apple should have these tools in place.
This one on the other hand, is a logical bug (interpretation of return codes) which is relatively harder to track especially when the use of said return codes is not consistent throughout the project
What you're talking about is decoupling interface from implementation. This is good (well, it's good if there is a genuine need for more than one implementation, otherwise it's just decoupling for the sake of decoupling which is a form of waste. Remember YAGNI)
My understanding of reuse is when the same peace of code is used in different areas of the project. This could be different classes, different packages, different modules, etc. Now the more the code is reused, the more tight coupling between the two pieces of code i.e. change to the interface of the reused code 'could' mean change(s) to each and every place the reused code is being called.
Secondly, if you put reuse high up in the design requirement, what you sometimes end up with are very generic interfaces/classes that can be reused in lots of places as opposed to very specific interfaces/classes or unnecessary inheritence trees required to change the base class behaviour in those places where the required behaviour is 'slightly different'.
Lastly, not so long ago, DI containers did not support package private visibility. This means all injection (constructor, setter, etc.) required public visibility. This lead to a lot of developers also 'reusing' code even in places where they shouldn't just because they could i.e. it's right there!
From the article, the author clearly states he has issues with the DI-driven design in general; Spring just happened to be the DI framework he was using at the time. Guice or any other framework for that matter would not have made any difference.
Money quotes:
>>>> In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just for the sake of decoupling. Coherence and decoupling are opposing forces and I side with coherence.
>>>> So reuse and decoupling are opposing forces. I find myself siding with decoupling.
It boils down to TCO (Total cost of ownership). Paying a one-time cost of X doesn't equate to X being TCO for that product/service.
In a functional business environment, any business related software you buy, will need at least three things: hardware, other software (e.g. operating systems, databases, etc) and support engineer(s). All these have recurring costs; ranging from monthly (engineers) to a few years (hardware). To know how must a software truly costs, you'll have to work out all these costs first.
Put another way, SaaS demystifies the whole TCO to a single recurring figure which you can compare to value/benefit you derive from the software.
Two other considerations for SaaS which the OP didn't discuss:
i) Wise investment. Is it wise for a startup/SME to invest $XXXXXX upfront in purchasing a software while they could pay $X (a fraction of the XXXXX) for a few months/years while studying the business and pivoting if necessary.
ii) Core business. If the software is not actual core to the startup/SME line of business i.e. it is just support system, shouldn't the startup/SME let someone else make sure that it works and just use it when needed (pay for when it's needed)?
For all the Angular.JS beauty and promises, I can't get past their decision of 'extend' a document mark-up language (HTML) into a 'full' programming language with loops, flow control, etc.
We might as well start developing browsers of the future in which the script (be it JavaScript, Dart, etc) get served first and then the script loads the HTML if we feel web apps are now the first class citizen of the browser and static documents second. But merging the two... I just don't grokk it.
I think the correct question should be: Is it worth your time learning any of the SPA (Single Page Application) MV* JavaScript framework (Backbone, Ember, Angular, Knockout, etc).
Browsers have come a long way. It's now possible to develop web applications that offer comparable user experience to say iOS/Android/Windows etc. As with those other platforms, to get the full user experience, the developer usually has to learn and use their native libraries and languages (Object-C for iOS, Java for Android, etc). For the web, the language is JavaScript and the library is HTML5 (the DOM manipulation that is).
Unlike those other platforms, plain JavaScript + DOM manipulation can get out of hand pretty quickly. It works when to create 'web application' means adding a few jQuery DOM manipulations here and there, backed by your favourite server framework. But when the amount of JavaScript you have to write grows, you need a way to structure it (design patterns, modules, etc). GWT, if I remember correctly, tried to address the issue of unmanageable JavaScript by allowing you to use Java on the server side and then it will compile and serve JavaScript to the client. This seemed like a good idea but the problem still remained: You're essential writing software in one platform to run in another. There will always be a penalty somewhere (do you remember how long it took to get the first JavaServer Faces framework with HTML5 render?).
The basic driving force of MV* JavaScript framework is to address the issue of writing clean, manageable and performing JavaScript code targeting the browser itself and not some intermediate platform. With the end goal being to provide a better user experience.
Is this worth learning? Well, do you think applications built using client-side JavaScript provide better user experience? Think Twitter, Gmail and the likes. Do you think your clients will appreciate such kind of applications?
This argument does not make sense at all. Almost everything we do or own in the real world is based on one form of hierarchy or another. Work (CEO > Executive > etc.), Home (Parents > Old Siblings > You > etc), House (House itself > rooms > closets in a room, etc.) These are not just labels and there is nothing geeky about them either. They imply a certain order or sequence of things that can not just be moved around. If there is one thing that we as people are good at, it must be hierarchies.
Tags on the other hand do not imply order of things. They are more about how you'd describe or how you relate to these things. For example you can have a 'favorite' tag and apply it both to your sibling as in 'your favorite sibling' and one of your closet as in 'your favorite closet in your room'. It says nothing about the order of these things just that your like them. Also, tags can be somewhat temporal as opposed to hierarchies. For example if we take a folders and files example, I can have a top level folder called projects which contains sub-folder for each project I've ever worked on. In each of these sub-folders I can then store the project-specific files. I can use 'current' tag to tag the project I'm currently working on. When I finish this project and get another project, I then remove the 'current' tag from the just finished project and move it to the new project leaving the hierarchy intact.
The point is not to use folders when you need tags or use tags when folders are required. The best files system would be the one that allows you to use both as situation demands.
Of all the basic version control intros/books, for me nothing beats Version Control by Example[1] book. It first explains the core concepts/commands behind version control such as create, commit, etc and them it goes on to illustrate how these commands actually implemented and used in practice using different version control systems.
The explanation is given for both centralized version control systems, using SVN, as well as for distributed version control systems, using Mercurial and Git (and Veracity).
Give it a try. The digital editions (PDF/EPUB/MOBI) are free for download I think.
"1. Recompile the Java code. 2. Stop your web server. 3. Redeploy the changes to your web server. 4. Start your web server.
...
Unfortunately, hot deployment has never been 100 percent reliable, and the web server often still has to perform expensive recompilation of code."
- Last I checked
i) the hot deployment in Tomcat/Jetty/SBT/etc is pretty solid, especially if we are talking development.
ii) Java supports incremental compilation which means you only need to compile what has been changed, especially if we are still taking development phase again. Unless you compile after making changes to 100+ files, I don't see how expensive this step can be.
"Generally speaking, Java-based web frameworks don’t reliably allow you to have a fast turnaround time for your changes. But that isn’t the only concern with Java-based web frameworks. Another factor that slows down rapid web development is the flexibility of the language, and this is where static typing can be a drawback."
- This argument about dynamic typing faster/better than static typing is just BS. Each offers it's own advantages and can be better/faster depending on where/when/how you apply it and how good a developer are you at actually using their power. Your first example of changing number value to have decimal precision can be achieved in static typing languages like Java/C# just as fast and reliably when one uses refactoring. Your second example of changing list of Book objects to a list of BookOrToy objects, could have been avoided all together by coding to interfaces and not concrete objects. If that has failed, refactoring again solves this.
Google (at least Gmail), LinkedIn, etc are to me modern web applications & AFAIK they are written in Java (or at least partly in Java) and I'm not counting countless enterprise web apps.
Java is what they call mature technology. It's past the hype and language flame war phase. Those who know its value, just use it to GTD without any ceremonies.
"detected using at least one of the technologies we track in this group" - does this mean some technology usage could be higher but it's absent because they're not tracking it?
Frameworks - How the hell do they "track" some of these frameworks here because the produced html/css/js could look exactly the same coming from say flask on python and jersey/jax-rs on java?
My understanding exceptions only bubble up if they weren't handled at the point of failure. This is exactly the same if you don't check the return type of a function that could return error. Both of this situations point to poor programming technique rather than underlying implementation option.
One thing that makes me currently prefer exceptions to error returns is that within a try/with block you can write the code as you'd like to happen and hence easier to understand and maintain. All exception handling can happen within the respective catch blocks.