Modern Digital Website Security: Prepare to face any form of malicious web activity and enable your sites to optimally serve your customers.
Low-Code Development: Learn the concepts of low code, features + use cases for professional devs, and the low-code implementation process.
Technical Architect at 6st Technologies
Chapel Hill, US
Joined Sep 2011
About
I write code and sometimes draw diagrams.
Stats
Reputation: | 4079 |
Pageviews: | 2.0M |
Articles: | 20 |
Comments: | 188 |
Articles
Refcards
Salesforce Application Design
Trend Reports
Microservices and Containerization
According to our 2022 Microservices survey, 93% of our developer respondents work for an organization that runs microservices. This number is up from 74% when we asked this question in our 2021 Containers survey. With most organizations running microservices and leveraging containers, we no longer have to discuss the need to adopt these practices, but rather how to scale them to benefit organizations and development teams. So where do adoption and scaling practices of microservices and containers go from here? In DZone's 2022 Trend Report, Microservices and Containerization, our research and expert contributors dive into various cloud architecture practices, microservices orchestration techniques, security, and advice on design principles. The goal of this Trend Report is to explore the current state of microservices and containerized environments to help developers face the challenges of complex architectural patterns.
Low Code and No Code
As the adoption of no-code and low-code development solutions continues to grow, there comes many questions of its benefits, flexibility, and overall organizational role. Through the myriad of questions, there is one main theme in the benefit of its use: leveraging no-code and low-code practices for automation and speed to release.But what are the pain points that these solutions seek to address? What are the expected vs. realized benefits of adopting a no- or low-code solution? What are the current gaps that these solutions leave in development practices? This Trend Report provides expert perspectives to answer these questions. We present a historical perspective on no and low code, offer advice on how to migrate legacy applications to low code, dive into the challenges of securing no- and low-code environments, share insights into no- and low-code testing, discuss how low code is playing a major role in the democratization of software development, and more.
Data Pipelines
Data is at the center of everything we do. As each day passes, more and more of it is collected. With that, there’s a need to improve how we accept, store, and interpret it. What role do data pipelines play in the software profession? How are data pipelines designed? What are some common data pipeline challenges? These are just a few of the questions we address in our research.In DZone’s 2022 Trend Report, "Data Pipelines: Ingestion, Warehousing, and Processing," we review the key components of a data pipeline, explore the differences between ETL, ELT, and reverse ETL, propose solutions to common data pipeline design challenges, dive into engineered decision intelligence, and provide an assessment on the best way to modernize testing with data synthesis. The goal of this Trend Report is to provide insights into and recommendations for the best ways to accept, store, and interpret data.
Enterprise Application Integration
As with most 2022 trends in the development world, discussions around integration focus on the same topic: speed. What are the common integration patterns and anti-patterns, and how do they help or hurt overall operational efficiency? The theme of speed is what we aim to cover in DZone’s 2022 "Enterprise Application Integration" Trend Report. Through our expert articles, we offer varying perspectives on cloud-based integrations vs. on-premise models, how organizational culture impacts successful API adoption, the different use cases for GraphQL vs. REST, and why the 2020s should now be considered the "Events decade." The goal of this Trend Report is to provide you with diverse perspectives on integration and allow you to decide which practices are best for your organization.
DevOps
With the need for companies to deliver capabilities faster, it has become increasingly clear that DevOps is a practice that many enterprises must adopt (if they haven’t already). A strong CI/CD pipeline leads to a smoother release process, and a smoother release process decreases time to market.In DZone’s DevOps: CI/CD and Application Release Orchestration Trend Report, we provide insight into how CI/CD has revolutionized automated testing, offer advice on why an SRE is important to CI/CD, explore the differences between managed and self-hosted CI/CD, and much more. The goal of this Trend Report is to offer guidance to our global audience of DevOps Engineers, Automation Architects, and all those in between on how to best adopt DevOps practices to help scale the productivity of their teams.
Enterprise AI
In recent years, artificial intelligence has become less of a buzzword and more of an adopted process across the enterprise. With that, there is a growing need to increase operational efficiency as customer demands arise. AI platforms have become increasingly more sophisticated, and there has become the need to establish guidelines and ownership. In DZone’s 2022 Enterprise AI Trend Report, we explore MLOps, explainability, and how to select the best AI platform for your business. We also share a tutorial on how to create a machine learning service using Spring Boot, and how to deploy AI with an event-driven platform. The goal of this Trend Report is to better inform the developer audience on practical tools and design paradigms, new technologies, and the overall operational impact of AI within the business. This is a technology space that's constantly shifting and evolving. As part of our December 2022 re-launch, we've added new articles pertaining to knowledge graphs, a solutions directory for popular AI tools, and more.
Application Performance Management
As enterprise applications increasingly adopt distributed systems and cloud-based architectures, the complexity of application performance management (APM) has grown accordingly. To address this new set of challenges, traditional APM is making a push towards intelligent automation (AIOps), self-healing applications, and a convergence of ITOps and DevOps. DZone’s 2021 Application Performance Management Trend Report dives deeper into the management of application performance in distributed systems, including observability, intelligent monitoring, and rapid, automated remediation. It also provides an overview of how to choose an APM tool provider, common practices for self-healing, and how to manage pain points that distributed cloud-based architectures cause. Through research and thoughtfully curated articles, this Trend Report offers a current assessment of where real enterprises are in their journey to design APM approaches for modern architectures.
Kubernetes and the Enterprise
In DZone’s 2020 Kubernetes and the Enterprise Trend Report, we found that over 90% of respondents to our survey reported leveraging containerized applications in a production environment, nearly doubling since we asked the same question in 2018. As containerization approaches peak saturation, Kubernetes has also become an indispensable tool for enterprises managing large and complex, container-based architectures, with 77% of respondents reporting Kubernetes usage in their organizations. Building upon findings from previous years that indicate the technical maturity of containers and container orchestration, DZone’s 2021 Kubernetes and the Enterprise Trend Report will explore more closely the growing ecosystem and tooling, use cases, and advanced strategies for Kubernetes adoption in the enterprise.
Application Security
In the era of high-profile data breaches, rampant ransomware, and a constantly shifting government regulatory environment, development teams are increasingly taking on the responsibility of integrating security design and practices into all stages of the software development lifecycle (SDLC).In DZone’s 2021 Application Security Trend Report, readers will discover how the shift in security focus across the SDLC is impacting development teams — from addressing the most common threat agents and attack vectors to exploring the best practices and tools being employed to develop secure applications.
Low-Code Development
Development speed, engineering capacity, and technical skills are among the most prevalent bottlenecks for teams tasked with modernizing legacy codebases and innovating new solutions. In response, an explosion of “low-code” solutions has promised to mitigate such challenges by abstracting software development to a high-level visual or scripting language used to build integrations, automate processes, construct UI, and more. While many tools aim to democratize development by reducing the required skills, others seek to enhance developer productivity by eliminating needs such as custom code for boilerplate app components. Over the last decade, the concept of low code has matured into a category of viable solutions that are expected to be incorporated within mainstream application development. In this Trend Report, DZone examines advances in the low-code space, including developers' perceptions of low-code solutions, various use cases and adoption trends, and strategies for successful integration of these tools into existing development processes.
CI/CD
In 2020, DevOps became more crucial than ever as companies moved to distributed work and accelerated their push toward cloud-native and hybrid infrastructures. In this Trend Report, we will examine what this acceleration looked like for development teams across the globe, and dive deeper into the latest DevOps practices that are advancing continuous integration, continuous delivery, and release automation.
Containers
With a mainstream shift toward cloud-native development, more organizations than ever are realizing real benefits as they modernize their architectures with containerized environments. While this move promises to accelerate application development, it also introduces a new set of challenges that occur with a fundamentally altered software delivery pipeline, ranging from security to complexity and scaling.In DZone's 2021 Containers Trend Report, we explore the current state of container adoption, uncover common pain points of adopting containers in a legacy environment, and explore modern solutions for building scalable, secure, stable, and performant containerized applications.
Modern Web Development
The web is evolving fast, and developers are quick to adopt new tools and technologies. DZone’s recent 2021 Modern Web Development survey served to help better understand how developers build successful web applications, with a focus on how decisions are made about where computation and storage should occur.This Trend Report will help readers examine the pros and cons of critical web development design choices, explore the latest development tools and technologies, and learn what it takes to build a modern, performant, and scalable web application. Readers will also find contributor insights written by DZone community members, who cover topics ranging from web performance optimization and testing to a comparison of JavaScript frameworks.Read on to learn more!
Kubernetes and the Enterprise
Want to know how the average Kubernetes user thinks? Wondering how modern infrastructure and application architectures interact? Interested in container orchestration trends? Look no further than DZone’s latest Trend Report, “Kubernetes and the Enterprise.” This report will explore key developments in myriad technical areas related to the omnipresent container management platform, plus expert contributor articles highlighting key research findings like scaling a microservices architecture, cluster management, deployment strategies, and much more!
Comments
Jan 07, 2021 · John Esposito
I'm also far from expert re. networking tech. The simple idea I was trying to compress (probably not very well) is:
1. Packet-switching keeps a given message decoupled from a dedicated channel on the network. So the sender and receiver don't need to worry about anything beyond acknowledgment of receipt. This is the first abstraction, and is not hierarchical in itself.
2. On the Internet, the full set of actual channels used to transmit the message doesn't need to be known to any given sender or receiver. In a 'network of networks', decisions can be made relatively locally. This is the second, 'hierarchical' abstraction.
You probably know that much already. The interesting magic is in the way the Internet avoids O(n) connectivity. Much of this magic is in implementations of BGP (border gateway protocol). For me this was a good intro: https://www.researchgate.net/publication/327645872_Introduction_to_BGP
Dec 28, 2020 · John Esposito
Some key findings are now available here https://dzone.com/trendreports/edge-computing-and-iot
..with additional analysis to trickle out over the next few months.
Nov 19, 2020 · Milan Milanovic
Great list. Also consider The C Programming Language and probably Elements of Programming, although I haven't read all of the latter (even though it's short).
Oct 09, 2020 · Thomas Hansen
Yes, additional examples would be superfluous -- I agree that inheritance and other kinds of hidden complexity/epicycles built into OOP lead to huge loads of programmer-brain, compile-time, and runtime overhead.
You're going somewhere new and interesting with that 50% number. I'm sure that percent varies by domain (as well as specific codebase). When you're weighing trade-offs in 'the real world', you always do have some kind of number in mind..but probably not something easy to measure empirically, exactly.
For me, irresponsibly generalizing, I'd say the percent of times a pure function is easier in the long run is well over 50. I think I'm subconsciously adding weights for number and 'hardness' of system boundaries, projected longevity of codebase, guesses at likelihood and type of later modifications, imagined familiarity with codebase of future developers?...a lot of things you can't know until after the fact, but which you have to imagine in order to run a good optimization function in your head. It would be interesting to get a whole bunch of developers' subjective guesses on 'how often does it turn out that, when you can choose between a functional or an OO approach, the functional approach turns out to be more maintainable'..and see how much this is steered by things like available tooling...
Oct 09, 2020 · Thomas Hansen
I agree that boilerplate is ugly, Java verbosity is ugly, and most OO-heavy code I've seen in client codebases is flabby and brittle. I also agree that the lambda calculus is basically zero-overhead, which is awesome. And I also agree that algebraic, type-oriented programming (e.g. Haskell) makes reasoning about program execution trivial, compared with OOP.
But let's distinguish (a) programming as inference-pipelining from (b) programming as theory-building, and let's focus on one particular construct: the anonymous function itself. (I take 'anonymous function' to be the same as a pure 'lambda function' in Church's sense: just a mapping that derives from another mapping ad infinitum.)
As a way to avoid overhead within the inference pipeline, the lambda is superb. But as a way to capture a domain, to precisify knowledge about a domain -- that is, to build a theory -- anonymous functions are not so great. Yes, throwing everything into hilariously over-the-top 'agent names' like SomeLongNameForDoingAThingAsVerbFormIfier is ridiculous, flabby, and stupid, from the point of view of the inference pipeline. Yay monads.
But as a way to precisify knowledge about a domain, (1) applying a (computationally unnecessary) name always adds interpretive information, and (2) 'hypostasizing' an action (i.e. avoiding in-lining) makes the programmer's understanding of the domain more explicit. I'm thinking of what you get when you look through a class (or at least interface) diagram (with suitable filters for the current level of detail), or a list of method names within a class, for nicely written OO code, in a good modern IDE (I'm used to IntelliJ but I think they all have good higher-level browsing features now).
If the programmer's understanding of the domain were perfect, then the functor-style expression of the domain would be the best kind of representation. But since the programmer's understanding is (highly variably!) imperfect, it's often super helpful to have some idea of what was going on in the programmer's head SEPARATELY from what the code, as compiled/interpreted, actually expresses. The degree of mismatch varies a metric crapton, of course. But I think that, for instance, frameworks do very well expressed in a functional paradigm, while enterprise code often prefers an OO approach, is partly the result of the relatively small programmer-domain mismatch in the case of frameworks and relatively large programmer-domain mismatch in the case of an enterprise system. (There's also the fact that many organizations tend toward hierarchy in a way that makes OO inheritance kind of make sense sometimes, even when from a pure programming perspective inheritance should automatically feel perverse; and the fact that large businesses like their programmers to be fungible, which any message-focused paradigm should play nicer with; but for the purpose of this comment I'm assuming only one programmer in a generically complex, poorly understood domain.)
Sep 22, 2016 · Sam Atkinson
Re. mechanics of pairing and cognitive effect: I've never used any formal 'pair programming' method, but in one coding job I did have a (senior) colleague often looking over my shoulder and mostly offering positive suggestions. In spite of our excellent relationship I still didn't feel like I could solve the 'big' problems with someone else present. This may be just a personality thing (I'm Myers-Briggs INTP, much more common among developers than in the general population; here's a recent survey of empirical work on personality tyes in software engineering), or maybe just the lack of a previously-defined method didn't leave me the headspace to tackle more complicated issues. But it did make my code better..although again maybe just because the other guy had a lot more experience. :)
OOC has anyone tried this pair programming method? (Didn't know anything about it until I interviewed two practitioners/inventors here.) I like the idea of investing in the relationship by forcing a shared and oral/aural understanding of the code, and it kind of does seem to formalize the sort of really valuable random coding chit-chat that can break you out of tunnel vision..but again haven't tried it myself.
Sep 08, 2016 · Ralph Soika
Relevant feedback from an anonymous user (re. why it's better to trust Java EE):
Sep 06, 2016 · Emmett Coin
Nice! What do you think of those 'move your mouse around randomly' true-random input systems?
Aug 30, 2016 · Daniel Stori
on the everything-is-an-object philosophy see this 2002 'Monad Manifesto' straight from Jeffrey Snover (PowerShell was originally called 'Monad')
Aug 19, 2016 · Duncan Brown
We've got a Refcard on refactoring patterns here w/some book recs at bottom (including Martin Fowler's of course). The Kernighan and Plauger is BRILLIANT but not relevant to the OO stuff discussed in this thread.
Aug 05, 2016 · Duncan Brown
Re. your 'polyglot suspicion' point: speaking only for myself, I do have application-wide mental models that are coupled tightly enough to the 'trunk' language (or maybe that's really just 'my favorite'?) to exert some pressure toward sticking with the trunk language (yes, probably memory-managed OO) 'wherever it isn't ridiculously unnatural'. The DDD 'bounded contexts' concept is supposed to help here but (for me anyway) it's hard to avoid leakage from the application-level (and somewhat language-bound) model. It's been tricky to reconcile the academic, Lispy+systems side of my brain with the productive, managedOO+platform side of my brain. I'd say that 'more experience would help' but while maybe more experience necessary it's certainly not sufficient -- maybe 'though more polyglot experience' would work. But then the existing 'children of Algol' (or at least C) codebases exert their own momentum and takes cross-pollination from telecom or embedded or whatever to expand the set of productive languages in a given application (or even enterprise).
Re. language<->domain optimization measurement point: exactly -- the interesting delta would be diff([optimal for some deductive reason like 'no shared state'],[actual for whatever contingent reason(=talent+f(expense,costTermDecisionmakersActuallyCareAbout)+fadpressure)]).
Aug 04, 2016 · Sam Atkinson
Interesting point re. contractors & I've noted that as something to dive into -- thanks. The 'nobody claims not to use agile' point is good as well; that's why, later in the survey, we asked about specific practices. But just the normal English word 'agile' may have meaninglessly muddied the conversation here, since the opposite of 'agile [the English word]' is unequivocally bad. I wonder whether the word 'extreme' in XP also didn't help, but for the opposite reason -- that managers responsible for profits and losses were afraid to do anything 'extreme [normal English sense]'.
The commodification of developers is encouraged by heavyweight frameworks too, I think (because the more constraints the framework places on developers, the more similar each developer's work is going to be..all other things being equal, of course, which they never are; but I think you can actually hire 'a Java EE developer' and be much more confident that you're hiring the right person than if you just hire 'a Java developer who built enterprise apps'). Wonder how heavyweight framework usage correlates with certain SDLC methodologies..maybe someone has noticed something..?
(Also thanks for pointing out the wrong link -- fixed!)
Aug 04, 2016 · John Esposito
Full list we asked about (deliberately loose with 'methodologies'): waterfall, Scrum, Kanban, TDD, BDD, DDD, XP, DevOps, Pair programming. We received these as 'other' fill-ins (<10 for each): 2TUP, Ad Hoc, Agile, BizzDevOps, CI / CD, Code Reviews [we actually had a separate question about these], Code and fix, Feature driven development, GTD, iterative, Kaizen, Lean, MBSE, MDD, non-structured Agile, RAD, RUP, Programming mofo [haha], some concepts from PMBoK, rapid prototyping. Don't know if this responds to your 'pretty stacked' comment though..?
Aug 04, 2016 · Duncan Brown
The thought-model/brain-expansion observation is nice -- thanks.
Would be really interesting to look at the model<->language mapping the other way round -- i.e., to know how languages distribute over problem space -- to put numbers behind intuitions based on historical yarns and deductive pictures derived from the language's preferred paradigm. For example, maybe I understand in principle why Lisp (or any logic-focused multi-paradigm language) is good for AI and that historically it has often been used for AI (maybe less modern narrow AI)), and that Erlang and Go are designed (for historical and CSP reasons) to handle concurrency elegantly and robustly. But how much of the AI problem space is actually covered by Lisp, the scientific/FP-heavy/array-dense space covered by Julia or Fortran, etc.?
I don't know how to measure this. LOC count, project count, PageRank-like library usage metric, languages used in papers by grouped topic and ranked by h-index all seem to fail (for different reasons).
Aug 04, 2016 · Sam Atkinson
We do have a bit of recent survey data on how developers feel about agile..prelim notes here, but we'll be publishing more soon. One interesting correlation that kinda confirms a few things people have been saying in this thread: for many methdologies and techniques, experience pushes 'highly positive' feelings to 'positive' (i.e. years of IT experience correlate negatively with estimated degree of method/technique utility). (Email me if you'd like to discuss further / suggest correlations to check -- we're not done analyzing our data yet.)
Aug 04, 2016 · John Esposito
Perhaps :) btw how do these results square with your experience?
Aug 03, 2016 · Duncan Brown
What are you talking about, of course the only way to start programming is Lisp via SICP, then Kleene on finite automata. ;)
..but seriously I wonder whether 'which problem you solve first' is more important than 'which language you learn first'. My first programming job was automating some MSAccess reports and I'm pretty sure this has left a strong relations+procedures stamp on my brain.
Jul 25, 2016 · John Esposito
Ah! this one would be great to look into further..esp how stateful->stateless refactoring rate changes over time (as code rots) and by various static metrics (since as you say there's a lot of risk&uncertainty pressure NOT to refactor where many objects are stateful).
Jul 20, 2016 · John Esposito
Fair point -- didn't want to steal the paper's thunder. But Tables 3 and 4 now added so you can skim reasons without downloading the pdf. :)
Jun 27, 2016 · Dave Fecak
FWIW, I use the free Mingle tier (for a three-user, on-and-off side project) and it does everything I need. Pretty straightforward, nothing too fancy.
May 22, 2016 · Matthew Casperson
problem whenever tech is used by people who don't really understand it -- including method, including scientific method: http://calteches.library.caltech.edu/51/2/CargoCult.htm
May 21, 2016 · Sam Atkinson
Love it. But a thought on persuasion:
Amortize cost of speed decrease over projected application lifetime, discounted by uncertainty of application lifetime length and future runtime environment. Compare with cost of coupling tightness increase introduced by eager optimization, discounted by uncertainty of code inflexibility cost over time. Add extra weight to represent fraternal concern for future programmer trying to understand your code, on top of cash wasted on that programmer's struggling-through-your-hyper-optimized-code hours. SO many uncertainties about the future -- but at least right now I know I can make my code cleaner. People normally discount future utility with apparently ridiculous weighting on uncertainty, but often generational breaks ("what will this do to my grandchildren's world") override. Maybe the social argument -- the responsibility to future coding generations -- will sometimes be more persuasive than appeal to code cleanliness through itself? since it is fairly certain that other people will have trouble writing your eager-optimized code, while the relative cost of your brittle code versus your eagerly-performance-optimized code over time is much less certain.
Anyway I felt much worse when contacted by a poor puzzled programmer two years after I abandoned a codebase than when I wasted my own time trying to figure out what my undocumented epicycles were trying to do in the same blocks (of course it was a horrid optimization specific to the local network config).
May 20, 2016 · James Sugrue
Perfect, thanks!
May 19, 2016 · James Sugrue
Interesting..will multi-window support work with any apps? and/or is there a new API to let you handle behavior in a non-focus window more precisely? (Apologies if this was discussed in the keynote, which I missed!)
May 19, 2016 · James Sugrue
Couple of closing curlies were missing -- added them. @Peter, are we missing something else?
May 18, 2016 · Alan Hohn
This makse sense to me..design patterns are accidental in Brooks' sense like pointed arches are accidental to stone ceilings -- of course they're one way to take advantage of stone's compressive strength (that's just a fact), but the selection of pointed-arch pattern should flow from the global design of the building. If you inject pointed arches just because they solve the 'ceiling' problem, and wooden lintels because they solve the 'need tensile strength' problem, then you may end up with something fragile and bizarre...
May 05, 2016 · mitchp
Email me (see my comment in reply to Shai's comment above) the url of the article you're waiting on and I'll check status.
Pending articles on profile are definitely on the way! :)
May 04, 2016 · mitchp
Nice!..merge/pull could work especially well for certain kinds of writing (for example, multi-author articles on best practices..some of which branch by paradigm, language, philosophy, constraints..). We're playing with diffing displays but man UI can be tricky. Great ideas, thanks -- anyone else want to chime in?
Markdown support is definitely on the roadmap. (We already support it in the commercial version of our platform.)
Got your email & will reply shortly.
May 03, 2016 · mitchp
Good questions, and sorry for the lack of feedback/transparency. Normally we aim for max two days from submission to feedback (rejection, editorial suggestions, or schedule to publish), but lately we've been missing that number pretty badly (combination of short staff and some new bugs in our moderation system). But we'll be expanding staff significantly over the next few weeks, so we should be able to provide feedback much more quickly very soon. Thanks your patience while we ramp up.
@Shai, I don't see any articles in moderation under your username (sa74997) -- do you happen to have the preview or edit url? Might be easier to email me (myFirstName+left(myLastName,1)@dzone.com) in case we need a little back-and-forth to locate your piece.
On transparency and feedback/improvement in general: what kind of info would you like to see, besides reads and likes on each article? We're actually gathering contributors' thoughts on an 'author analytics' page right now, so feel free email me about that too. Would love to hear more & can probably share screenshots of our current draft, if you're interested.
May 02, 2016 · Emmett Coin
Wow, Semantic Scholar looks awesome! Thanks for posting. Can't believe I haven't run into it before.
Apr 28, 2016 · Dave Fecak
On the general issue of public code hosting service fragmentation: getting these just right seems like a very subtle developer UX problem, clearly something GitHub hasn't solved. I know GitHub/GitLab/Bitbucket are all pretty great, but I wonder how effective the user feedback cycle becomes when a service hosts code from many mostly unconnected communities.
Variance in platform feature requirements doesn't have to come from technologies (languages, platforms, heavyweight frameworks) alone, but even (and probably more so?) from the way the particular community actually uses and shares code. But I don't know how the feedback cycle works for those platforms, esp. since their business models seem different. Is there a need to pool usage data and user feedback across source hosting platforms? I wonder if that's something we could facilitate.
Apr 28, 2016 · Dave Fecak
The "explain changes that affect a community thoroughly and very openly" point is reminding me a little of when we relaunched dzone.com on our own platform last year..and we thought well of course everyone would be happy because the new site is so much prettier and faster and easier to use than the old one! and of course in the end it was a good move, I think. But we re-learned how much full communication with our developer community matters, and re-realized how easy it is for someone who provides a platform for a highly invested community to start feeling more like a generic service provider (like how you're describing Google Code) and less like a participant in the community (as Java has been for a long time).
Apr 26, 2016 · Matt Werner
Definitely want to keep this a serious tech discussion site! What seems like advertising in this piece? (True, it's about skills rather than code directly; but recently articles about career and skills development have been received by our readers quite well, and have often generated substantial discussion.)
Apr 24, 2016 · Daniel Stori
Yeah I haven't seen the movies either but back in grad school everyone talked about the Saw movies (grad students disproporionately enjoy horror movies for not-too-hard-to-figure-out reasons) so I learned the name 'Jigsaw' and understand the basic premise at least (still haven't seen any -- no spoilers! maybe they're good). I like how the last panel acknowledges, engages, and comically deflates some recent (perhaps well-justified!) fears around the future of Java...
Apr 16, 2016 · Daniel Stori
Still not invented: an awk that works on self-and-other's memories of all past conversations in relationship_history.log.
Apr 07, 2016 · Sam Atkinson
Haven't myself read Sam Newman's book, so I can't speak to its contents in particular. But while the general ideas behind microservices aren't new at all, as you note (you might say they're as old as Unix, but you could also trace the concepts waaaaay farther back in organizational management and military contexts), a few technical features taken together (single-process services, independently linked backing resources, web-based and often human-readable IPC) and system-definition and internal communication principles (the 'bounded contexts' of Domain-Driven Design in particular) are turning the commonsense notion of loose coupling into a really practical architectural style.
Before I read Eric Evans' DDD book and this post by James Lewis and Martin Fowler I also felt "no duh" about the whole microservices buzz. Maybe I should also read "Building Microservices", though. :)
Apr 04, 2016 · Daniel Stori
:'(
Feeling guilty for every kill -9 from here until forever...
Apr 02, 2016 · John Esposito
Yep, Sar had actually created a simpler version and then I asked him to make it harder -- so it's entirely my fault on that front. :) Juggling more values*abstraction-levels than the brain has registers can be so much fun, though..!
But this gets me thinking: what do y'all think of the following:
- In some cases, we can publish two versions of the same quiz -- one easier, one harder. (For example, @Sar, I know you already have an easier version of this quiz.) Then the reader can try the easier one first, and if they solve it without too much trouble, they can try the harder one.
- In the trickier cases, we'll include an explanation of the correct answer in the response to an incorrect submission..and come to think of it probably in response to a correct submission as well, in case your reasoning included a measure of hunch.
How does that sound?
Apr 01, 2016 · John Esposito
Hmm can you clarify? I don't understand what you're getting at, but I would like to. :)
Mar 31, 2016 · John Esposito
Glad this is now clear! -- thanks @Adam and @Sar. :) Would "Java Puzzler" or "Java Brain Teaser" be less confusing? @Ben, your thoughts on the series title are also welcome, of course.
Mar 31, 2016 · Sam Atkinson
@Martin and @Hung, have you run across any useful patterns, rules of thumb, design principles, best practices, etc. for microservices?
To understand the kind of concretes you're talking about (how to define boundaries, manage interaction..the stuff you still have to figure out after you get the idea) I usually take an onion-skin approach: look first at deeper/broader concepts (say, Eric Evans' DDD, or the book Sam recommends), then at design patterns (to capture something of real development experience), and third at complex, real-world examples (to see an actually working system in detail), preferably with lots of readable code annotated to explain design intent. Architectural diagrams from multiple perspectives help me a lot, too -- not just a physical or logical architecture, or class diagram, or control or dataflow diagram, but all of the above.
These books are some of my favorites for the 'from paradigm to examples' shift. Many articles include material at all of these levels.
Mar 31, 2016 · Duncan Brown
Brilliant site. Well-tagged, too.
Mar 30, 2016 · Sam Atkinson
Sure, that's what Sam pointed out in the article -- probably lazy won't help, but of course if it does (e.g. frequently opened db connection) then adjust accordingly.
As I understand James' image in relation to the article: the article proposes a rule of thumb that instantiates the general point Knuth is making -- and ∀-rules and thumb-rules both introduce constraints that reduce decision space and thereby stress etc.. 'Less thought required' isn't as good as 'without any extra thought required', but it's getting there...
So to flesh out the thumb: what are some other 'exceptional cases in which lazy initialization really does make sense'?
Mar 30, 2016 · Duncan Brown
Ha, good idea, thanks! Mild embarassment in one's own eyes can indeed be a great motivator to better code...
Mar 29, 2016 · Duncan Brown
Ha. Would say "no duh" except that I can't count the times I've smacked myself in the head for leaving database connections open.
There should be a "Checklist for Bad Things You Knew About Ten Years Ago But Still Do Anyway".
Mar 26, 2016 · Stefan Wolpers
This is a great point that Stefan's article addresses but hasn't come up much in the comments so far. Agile is all about delivering value to the customer, maintaining a sustainable development pipeline, building honest relationships among engineers, business people, customers, etc. But how does the development of individual developers' skills fit into this?
Pretty deeply, I think -- at least if the project goes well. For example, in maybe my most successful coding project, my manager was my (older) brother, who wasn't a developer but was technical enough to translate requirements and implementations both 'down' to/from me and 'up' to/from the users (all internal). He and I already had a great relationship and knew how to communicate with each other quite well, so personality mismatch wasn't an issue. Before that project I was still in a 'dump more and more procedures into a few fat classes and call it object-oriented, and slap some boxes and buttons on top of some tables and call it a UI' mode and figured that he'd only help me make my forms look pretty -- but in fact I ended up redesigning more than half of the application just because I always had a high-bandwith line to the end-users. This one project made me grow a lot as a developer (or at least I think it did!) -- not at a procedural level, but at the level of domain modeling and object-oriented design.
Can poorly-managed projects harm an engineer's growth, though? say, by encouraging him/her to grow suspicious of a method or philosophy because people messing things up are using the name of the method or philosophy as 'silencing' weapon or a band-aid (possibly with high opportunity cost), no matter what decisions they are actually making?
Mar 26, 2016 · Stefan Wolpers
Agreed. One annoying little word-magic issue is that you can't sound reasonable in a meeting if you object when someone says "We need to be more agile!" because of course "clumsy" or "unresponsive" aren't good..and over an oral/aural channel you can't tell whether "agile" has a capital 'A' and refers to the Agile Manifesto, the ideas and practices behind that text, or just a vague idea that "visibility is good" -- which can easily blur into "never trust an engineer".
DDD tries to address the doublespeak danger (good word-choice @Joel) at a substantive level, I think, without targeting any management philosophy in particular.
Mar 25, 2016 · Stefan Wolpers
Possibly interesting points, but can't tell if some wires are crossing here: why do you say "WRONG" to each of these claims?
My impression is that the article actually agrees with what you're getting at (if I understand you and the article correctly), but focalizes heavily in order to reflect the feelings that many developers that Stefan has worked with have actually expressed.
I've seen many of these complaints expressed before and have felt all of them myself. Too often, I think, when "Agile" is invoked, the real, inescapable engineering requirements (technical and organizational) are not sufficiently addressed. The word "Agile" becomes a cloak for not bothering to think with clear engineering sense -- that's the idea captured by the "cargo cult" phrase.
@Stefan, do I understand your points correctly, and @Marcelo is this also what you're talking about?
Mar 25, 2016 · Matthew Casperson
That's a good point re. mixing tools -- I could say that "in fact people do sometimes choose between JIRA and GitHub for issue tracking because GitHub Issues isn't too shabby so if you're using GitHub maybe you should just stick with the built-in feature and not worry about another tool?" but that lumps things together in a general conversation (the article) that only happen to be lumped together in a particular situation (my choice point).(On the other hand, my Unix side wonders whether the size of many tools' feature-sets and the resulting feature overlaps among tools -- the things that make these heterogeneous option sets available in the first place -- aren't just mistakes inherited from factory-centric organizational design principles.)
Thanks for the feedback. Title changed.
Mar 24, 2016 · Matthew Casperson
That's true (also @Csaba), but you might have to choose between option (a) which includes TFS and not Git (even though TFS does support Git -- say for solution-integration reasons, like "we're going to use TFS only with TFVC") and option (b) which includes Git and whatever other ALM stuff. So I think the title seems a little apples-to-oranges but sometimes in actual moments of choice -- because in-prod technology selections are not atomic -- you do have to choose between apples, on the one hand, and oranges, on the other.
Mar 08, 2016 · Dave Fecak
A bit orthogonally: if Paul Lockhart is right, then math will be very hard to teach non-pathologically for at least the current, and probably also current+1, generation of teachers. Lockhart's argument really jives with my experience -- I had to unlearn years of robot-brain nonsense in order to do any linear algebra without hating the universe. (This book helped in all sorts of ways, although I wasn't mentally ready for it until Better Explained had already convinced me that a big part of the problem was the pedagogy.)
A bit less orthogonally: totally agree that coding doesn't have to be learned in college, that undergrad CS degrees teach a lot that rarely comes up in many (managed-memory) developers' coding lives, that university education is often a huge waste of money.
One issue, though: when you do need to start thinking about deeper stuff like linear programming, Bloom filters, state machines, Lamport clocks, etc., where do you learn that? I don't know any good centralizing resource (so, Google?) -- MIT OCW, if I had to pick one, but that too is so far from user-friendly.
Mar 08, 2016 · Dave Fecak
public class lol extends laugh
Feb 19, 2016 · Matthew Casperson
Yes! :)
Feb 17, 2016 · John Esposito
Oh very interesting..thanks for the book note. Do you recommend it?
100% understand re. programming in types. Have been stabbing at this book on and off, and feel like I have occasional epiphanies while reading various bits, but nothing concrete enough to apply in code.
Traits are interesting too (and more intuitive for me), and someday I'd like to see what it's like to program in Rust..on whose type system I found this post helpful...
Feb 16, 2016 · John Esposito
The NPE and syntax features are really nice though. :) But yeah afaik the biggest diffs between Kotlin and Groovy are Android (possible in Groovy but slow) and IDE (supposedly Kotlin is lovely in IntelliJ, as you might expect, though I haven't tried it myself) support.
The study I linked re. why devs choose a language (not the feature-set) is probably a bit skewed by professional convenience, rather than for fun/curiosity, so if you're wondering about just playing with Kotlin for now then maybe think of it as 'easier Scala' or 'faster Groovy'..but I haven't built anything serious in it so can't verify that independently.
We can also ask the project lead about diffs vs. Groovy..got an interview lined up..!
Feb 16, 2016 · John Esposito
learnyouahaskell is on my reading list, if that's what you're getting at. :)
..and honestly I generally do feel more functional than OO. (Keeping the 'Lisp is beauty incarnate' tag in my bio permanently -- or maybe until I learn me a Haskell!) The knock on lambdas was a bit of a joke, lightly mocking (say) Smalltalk zealots who actually hate anything that isn't deeply messaging-focused.
Feb 16, 2016 · John Esposito
Yep, we're open to this kind of thing -- to start, please fill out this Refcard proposal form. Reply here if that doesn't work..just switched this out from Google Forms and a few users have had a little trouble (that mysteriously went away on its own). Thanks.
Feb 16, 2016 · Deepak Karanth
For something a little different, what do you think of SICP or Bryant and O'Hallaron? SICP helped me bridge abstract compsci coursework with actually writing code, and Bryan and O'Hallaron (which I admit I haven't read fully) helped me decide how much to trust compiler guesses and runtime abstraction (for me this meant .NET).
I've only read about half of your list and now have loads of great-looking reading material -- thanks for this post. :)
Feb 15, 2016 · Chelsea Bosworth
True. Sometimes release plans clearly indicate what will not be backwards-compatible. For 'known factors on the horizon', would an in-line code tag/taxonomy help? in case the release plan doesn't specify what will change at a level concrete enough to search for substrings (class names, methods, keywords) in the codebase. Thinking something like ReSharper, but for the future. If such a taxonomy were standardized, then changelogs could also be released in this format, semi-automating any refactoring you might have to do to keep your code up-to-date.
For 'computing past trends', I don't know how to do these in a domain-independent way (like a VAR model or somesuch). How would you construct a predictive model based on singular, engineering-specific cause-effect pairs like 'the effect of the the rise of inexpensive multiprocessing on parallel algorithm selection'? Maybe there's a way within a given platform space ('how fast do JSRs move' or 'how frequently do JS MVC frameworks require shims for backward compatibility')?
Problem space modeling failure and domain change can both be measured, I guess. But the latter seems especially hard. How frequently do requirements change after the initial release, and how deep in the code/architecture do those changes cut (measured by function points..again expensive)? Projected domain change rates would have to come from domain experts, translated into code-impacting ways via some method like DDD context maps or Gherkin. That would be neat, though.
Feb 11, 2016 · Chelsea Bosworth
Interesting..could you attach {rate of staleness increase by time unit, final stale-by date, {set of independent variables with relation to the first two} to individual features, feature sets, packages, or actual code blocks? so like (to pick a simple version) "this component will be stale as soon as the next version of MySQL is released because we know the new API won't be 5.6 compatible" (but as a machine-readable, hierarchical tuple).
Feb 11, 2016 · Chelsea Bosworth
Good points -- both could be added as weights in a slightly (but not massively) more complex model -- are you aware of any research in this direction? I know the literature is vast and my quick Google Scholar search doesn't yield any easy answers.
Re. 2c though: is there an inverse relation between non-deliberate technical debt accrual and accuracy of feature point record? But the opposite for deliberate technical debt accrual (since presumably you have some idea how much you're accruing if you do so deliberately).
In a perfect model, function point analysis would also be necessary, I think (otherwise the systemic impact is invisible). But also very expensive.
Jan 29, 2016 · Imesh Gunaratne
Nice, thanks -- and wow, what a cool wiki page!
VMWare's deep-dive into how they virtualized x86 is also a beautiful read.
Jan 28, 2016 · Shidram BJ
Should be fixed! :) Does it appear in your article list now?
Dec 04, 2015 · James Sugrue
Nice, thanks. Harlan Mills is a high standard to live up to. :)
Dec 02, 2015 · James Sugrue
Neat! -- can you post a link to these studies? Would be interested to read further (esp. to understand what the authors mean by 'productvity').
Nov 20, 2015 · mitchp
Ahh, good question -- thanks! We're basically interested in two things: (1) does this help readers make better software? and (2) does this drive readers away? The trick is that hard-to-pin-down things like 'tone' and 'angle' can make (1) and (2) both true -- so if your post sounds like it's promoting a commercial product/service, then even if it's really just celebrating the open-source project that the commercial service supports, it might still rub readers the wrong way.
Does that help at all? Of course it's hard to tell tone 'from the inside' -- genuine enthusiasm to one person is prosetylization to the next! -- for now am just trying to give a sense of moderators' reasoning. Will try to find some examples (of 'this is fine' and 'this probably kind of crosses the line tone-wise') and include in the general guidelines post.
Nov 17, 2015 · mitchp
Section titles formatted as headings, paragraphs broken correctly, text flowing around images (or images breaking text) so that lines of text are longer than one or two words, code blocks formatted with readable line breaks and indentation (and commented if necessary), no meaningless whitespace. Does that answer your question? Maybe this should go in the article, too. :)
Nov 05, 2015 · Matthew Casperson
Not specifically about documentation, but related point re. high-level languages: http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
Nov 01, 2015 · Denzel D.
Makes sense, and I understand that religions about technology are always wrong (and lazy and harmful). But I just wonder why, psychologically, clean abstraction in particular keeps riding the zealotry bandwagon (this seems to be true in the JS world too..looking at you, Angular). True, immutability alleviates side-effect worries; but pure function machines will be incredibly inefficient or unpredictable (how can you allocate finite memory for absolute black boxes? although I think Rust's lifetimes try to address this) until context switching is costless and garbage collection instantaneous, which both seem impossible (thread pools and generation-interleaved garbage collection are good tries, I guess).
Psychologically, at least to me, it feels like desire to latch on to the One True Clean Abstraction is an attempt to ameliorate the incredibly frustrating juggle of humility (because you are certainly missing things you could not-miss), defensiveness (because you can't anticipate everything even if you miss nothing you could have thought of), and perfectionism (because, really, things unrelated ought not be related).
Nov 01, 2015 · Denzel D.
"A lot of performance issues come from impedance mismatches between programming model and what happens under the hood."
Right -- abstractions are never quite perfectly clean; the Shannon ideal doesn't distinguish code/decode from run. But mismatches go both ways..machine language doesn't map any problem domain very well. I guess downward (metal-directed) mismatch causes more trouble at runtime, while the upward mismatch (domain-directed) causes more trouble at maintenance time.
Microservices (at least as 'socially' implemented by 'feature teams') serve the upward nicely. But I wonder if this presents an extra danger. The upward is more visible from the outside than the downward impedance mismatch, so there's more management pressure to conform up rather than down. And powerful platforms (Java and .NET quite a bit; JS/browser probably a lot more) make it relatively easy to write code that gives you a working feature set despite massive inefficiencies arising from failure to attend to where how much data is going over which channels given which inputs etc..
Oct 31, 2015 · Denzel D.
OOC what about current microservices talk reminds you particularly of the EJB buzz, besides general overapplication of a hot tech for no good technical reason? is it also specifically the (not fully rational) attractiveness that derives from (self-flagellating? or at least emotionally self-serving) search for clean abstraction?
Oct 31, 2015 · Denzel D.
Shouldn't the social and technical be at least decoupleable, though? DDD helps design primarily and implementation only secondarily; in a way, the Conwayish comms structure is just a View. But yeah to me the main value of the microservice heatwave is that it pushes you to think DDD.
Socket-channeled microservices are no more panacea than Smalltalky message-passing, of course, but I think any talk about loose coupling is always going to sound appealing because when you run into pain thanks to tight coupling you don't just have extra work -- you also feel how stupid the earlier decisions were, and you get mad at whoever wrote this hideous spaghetti code. And then -- and here I'm speaking from inexperience, I guess, never having written anything as deep as a data grid -- you remember how many times, as you wrote your code, you felt sorely tempted to diverge from the clean separations presupposed by your architectural diagram, and you just want to drill the loose coupling message into your brain by keeping I/O as tightly gated as possible..so in your desire for self-manipulative self-improvement you jump on the loose-coupling-of-the-month/year bandwagon. (Though in my case I feel like this self-manipulating pressure will disappear with sufficient experience.)
Oct 10, 2015 · Rodrigo Kyle Mehren
Makes a lot of sense. Totally agree that debt without repayment plan is more like sucking life out of the future, not betting on the future.
But the distinction can be hard to apply, I think. For any non-trivial application, you always might be able to make the code more maintainable. Often you just aren't sure how the work-to-benefit ratio will pan out over n months, esp. if requirements are in flux. In the pure case this is just the Entscheidungsproblem, but workaday it happens constantly.
So how do you decide what's a mess and what's just..a bit rushed? :)
Oct 10, 2015 · Dave Fecak
Thanks, Dave and Shai. I've heard a growing number of opinions like this lately, especially from folks that not only have used Java but also have been passionately involved in the community for years..but also, on the other hand, a good deal of enthusiasm around Java 8 and occasionally even neato-and-apparently-somewhat-developer-driven stuff (FastR, Graal, PGX) at Oracle Labs. But I can't speak to this from my own experience.
On another note, any thoughts on how the JCP is doing now -- esp. re. innovativeness and openness -- vs. Sun or immediately post-Sun Oracle days?
Oct 10, 2015 · Tom Smith
Ha, thanks for catching those typos -- should be good now.
And Tom did gather a lot more about these players' roles during those interviews..stay tuned. :)
Oct 10, 2015 · Dave Fecak
Okay, I won't ask you about the DOM..for now. :)
Oct 09, 2015 · Dave Fecak
Good thought -- but is the hangup JS itself or just the DOM? For me JS syntax is fine -- it's just unpleasant to jam a marked-up-document peg into an object-oriented, somewhat-Java-inspired hole.
Oct 09, 2015 · John Esposito
Right -- so your claim as I see it is basically: getRateOfChange(Java, magnitude of change) < getRateOfChange(Swift, magnitude/change), where magnitude of change = f(depth*utility of language fundamentality per change). Correct me if I'm oversimplifying or misunderstanding. And you're not saying that Java isn't getting better, or that Oracle isn't doing a lot of work on Java 9, just that it's not growing as..swiftly..as Swift.
So I wonder whether we might expect the rate of fundamental change of a language to be inversely proportional to the size of the platform (say, classes*methods), and the size of the platform to be influenced, at least, by some function of both age and current size of userbase? In which case it just makes sense, no knock on the superplatform, that newer languages would reinvent themselves more deeply faster, like weekly-identity-swapping teenagers versus set-in-their-ways adults. That sounds better to me than 'mass and inertia' -- which of course could still be slowing things down on top of (and independently of) maturity-caused molasses.
More concretely: the number of times I've thought "Man, wouldn't it be great if this were already implemented somewhere!" is way larger than the number of times I've thought "If only this language were more like Lisp!" (no matter how much I'm in love with Lisp) precisely because Java (or, say, .NET) can already do so much stuff for me. So if I were to contribute to some JSR (which I haven't) then I'm much more likely to add features higher up than dig down and, say, add native support for a different programming paradigm. If I really want to do something a language can't do, I'll just switch languages, nbd.
I'm curious -- do you have an opinion on innovativeness in / deadness of .NET vs. Java? or for that matter W3C APIs?
Oct 07, 2015 · John Esposito
Interesting piece, Rob -- thanks. For us still-Java-lovers, though: can you suggest ways to give Java a back-to-life jolt? I get what you're saying about newer ecosystems seeming more vibrant and adjusting faster to real-world needs, but to me one of the most exciting things about Java has always been the JCP -- the whole point of which is to do exactly that. Do you think that process needs to change somehow? (Do we need to revive Apache Harmony..?)
Aug 24, 2015 · Matt Werner
Mike, thanks for this sensible article.
Re. frameworks, question: how do you factor in the uncertainty of the product plan? For example, you know with 80% certainty that you'll be adding feature X that framework F makes really easy in M months, but right now using framework G will save H hours over using framework F. Do you say 'break-even is M+N months' and just put it in a spreadsheet? or just: how do you weight future potential of a framework that you're choosing now?
Aug 17, 2015 · John Walter
This quote from Oracle seems particularly odd: "Given the widespread dominance Android has achieved with its continued unauthorized use of the 37 Java API packages over the past few years, Android has now irreversibly destroyed Java's fundamental value proposition as a potential mobile device operating system." (emphasis added)
Presumably 'Java' (something way more people than Oracle care about) here refers specifically to 'Java ME' (something that mostly Oracle cares about as a mobile OS). Android developers are still writing Java for a mobile OS, albeit platformized on Android rather than Java ME. The Java/Java ME slip (though legally correct, I assume) suggests a perspective far from the Java developer's.
Aug 13, 2015 · mitchp
Indeed! cf. the recent IEEE list -- interesting how different results compiled using a different method (from a bigger, more varied, and differently skewed data set) can be
Aug 13, 2015 · James Sugrue
Ross, thanks for sharing your current stack. The Java/threadpooling headspace is so different from async/non-blocking that I'm having trouble .
How is Angular 2 treating you? We've used Angular and it's really nice for highly mutable SPAs, but I'm not 100% sold on SPAs themselves..seems contrary to some vague idealistic ethos of the web...
Aug 13, 2015 · John Paliotta
Yeah, 25% of bugs are apparently in the requirements themselves, and another 25% are structural..according to some huge study I can't remember but can probably find if anyone is interested.
Aug 13, 2015 · Jane Berry
How important is the abstract compsci stuff, though? -- the part that kind of is a little magical, that makes it possible for putting-things-in-little-boxes-and-shifting-them-around to generate valid inferences, traverse graphs, calculate values of functions with arbitrary limits, pixelize projective geometry, do a massive linear regression in milliseconds?
Aug 13, 2015 · Jane Berry
Ha! Great article. Sort of the converse of Fred Brook's No Silver Bullet piece. Sadly I haven't done enough assembly to feel the magic of the JVM go away. But I see what Uncle Bob is getting at, and far too often I do hit 'wait a minute, that was incredibly simple..dammit' moments..that aren't revelations but just annoyances at my earlier (and damaging) magic-feeling.
Aug 12, 2015 · Elaine Harris
Ultimately this kind of info would be more useful in a structured catalogue, but rubygems.org doesn't provide use-case recommendations. Are there any structured directories of gems that let you, for example, list all ORM gems?
Aug 12, 2015 · Thorben Janssen
Hey, thanks -- that BLOBbing really sucks and this looks pretty easy.
Aug 12, 2015 · John Paliotta
Good thought -- and we're even publishing a forty-page 'Guide to Software Quality' in a few weeks. :) Would love to hear what you think of that longer treatment.
I guess unit tests seem like a great manager's-eye target because they are relatively easy (a) to create, (b) to measure, and (c) to interpret ('code coverage' is such a simple metric). Of course where e.g. integrations are likely to be sticking points, unit tests will be less likely to catch real errors..how much energy to put into which aspects of software quality will always be a business (resource-based) decision, grounded in but not completely determined by the software architecture.
Aug 11, 2015 · Ganesh Pol
I see how this might save resources, but won't this potentially make program behavior unpredictable (and also potentially degrade user experience)?
Aug 09, 2015 · Instanceof java
This seems extremely basic..maybe easier just to link to Oracle's Java Tutorials?
Aug 06, 2015 · mitchp
There are some pretty funny jokes in there, but the rest of the Twitter conversation seems to confirm.
Aug 04, 2015 · Matt Werner
Wow, this is quite a list. :) I've encountered many of these claims anecdotally but am wondering about response bias (how many developers would post praise of their good managers?) and I bet someone has done empirical work on this. Anyone have any supporting data, esp. for claims 1,2,4?
Jul 19, 2015 · Rick Delgado
Wow @Akmal that's an awesome slide deck thanks!!
On a related (get it haha) note: we've started to build an rdf/owl ontology of data stores (among other things)..would you be interested in lending us your expertise to make sure everything is correct?
Jul 19, 2015 · mitchp
Sounds like a good counterexample.
In general I see more good writing on exception handling antipatterns than positive exception handling patterns. Anyone want to suggest any resources on exception handling patterns, both language-neutral and language-specific? Best I know right now is the c2 wiki page.
Jul 19, 2015 · mitchp
Yes, 100%. Give me an ugly static HTML page and (these days anyway) decent odds are there's something worth reading on it. And my mobile phone&plan won't creak. On the other hand, as you say, we publishers need to make money somehow. :) But of course we only want publish people who already have something to say. But this can easily make the content<->ad match incidental and/or weak..so the basic cruft problem is unsolved even at a non-technical level.
Jul 10, 2015 · mitchp
Interesting! Have C++ and/or C# changed strings over time to such a significant degree?
Jun 23, 2015 · Benjamin Ball
and deeper still
Jun 23, 2015 · Benjamin Ball
deeeper in the thread
Jun 23, 2015 · Benjamin Ball
reply to a comment here
Jun 23, 2015 · Benjamin Ball
nothing is this hey this isn't a reply or is it??
Jun 23, 2015 · Benjamin Ball
what is a comment here it is
Feb 05, 2015 · John Walter
Wow, how did I not know about the Ultimate Hacking Keyboard..looks amazing! & thanks for the mention. Combine with keylogger, correlate with particular languages/frameworks, and offer downloadable 'keyboard for language L' layers.
Also wonder if different typing habits influence coding decisions at all. Ny fingers definitely remember lots of platform boilerplate, but are these muscle-memory patterns completely compartmentalized from muscle-memory generated by non-coding typing?
Feb 05, 2015 · John Walter
Wow, how did I not know about the Ultimate Hacking Keyboard..looks amazing! & thanks for the mention. Combine with keylogger, correlate with particular languages/frameworks, and offer downloadable 'keyboard for language L' layers.
Also wonder if different typing habits influence coding decisions at all. Ny fingers definitely remember lots of platform boilerplate, but are these muscle-memory patterns completely compartmentalized from muscle-memory generated by non-coding typing?
Jan 29, 2015 · John Walter
'Specific applications' is a good distinction -- do you use different layouts for different applications?
This question is interesting to me partly because I ran into this article on gesture keyboards, and it seems that one of the neat things about non-physical keyboards is that the layouts are very easily adjustable on the fly...
Jan 29, 2015 · John Walter
'Specific applications' is a good distinction -- do you use different layouts for different applications?
This question is interesting to me partly because I ran into this article on gesture keyboards, and it seems that one of the neat things about non-physical keyboards is that the layouts are very easily adjustable on the fly...
Jul 01, 2014 · fordevs devs
Impressive, thoughtful article -- thanks for the post.
As a matter of empirical fact, I guess, any code change de facto increases the chance of random bug popup. There's been some empirical work on the correlation of refactorings with bug reports, and overall it looks like refactorings and bug reports correlate positively. But maybe most of those generic refactorings were stupid or at least 'not best'. Figuring out which refactorings are 'best' is exactly what will help us get past the generic and into the actionable.
More granular empirical work on the cost/benefit of refactoring seems to have ballooned a bit over the past two years. I've only skimmed a few of these, but you might find some of these articles interesting.
Jul 01, 2014 · Benjamin Ball
Impressive, thoughtful article -- thanks for the post.
As a matter of empirical fact, I guess, any code change de facto increases the chance of random bug popup. There's been some empirical work on the correlation of refactorings with bug reports, and overall it looks like refactorings and bug reports correlate positively. But maybe most of those generic refactorings were stupid or at least 'not best'. Figuring out which refactorings are 'best' is exactly what will help us get past the generic and into the actionable.
More granular empirical work on the cost/benefit of refactoring seems to have ballooned a bit over the past two years. I've only skimmed a few of these, but you might find some of these articles interesting.
May 06, 2014 · John Esposito
Good questions.
But I guess my thought is that codebase c can be 'more agile' (=able to change direction quickly) than codebase c' even if both c and c' have the same heavyweight plans with the same degree of investment -- and that it's precisely the engineers (especially architects, presumably) who can make c as opposed to c'. (We'll need to distinguish 'good coding practices' that focus on maintainability and updateability from coding practices that produce agility measured in this rate-of-change (as opposed to rate-of-repair or rate-of-improvement-along-similar-lines way.)
May 06, 2014 · John Esposito
Good questions.
But I guess my thought is that codebase c can be 'more agile' (=able to change direction quickly) than codebase c' even if both c and c' have the same heavyweight plans with the same degree of investment -- and that it's precisely the engineers (especially architects, presumably) who can make c as opposed to c'. (We'll need to distinguish 'good coding practices' that focus on maintainability and updateability from coding practices that produce agility measured in this rate-of-change (as opposed to rate-of-repair or rate-of-improvement-along-similar-lines way.)
Feb 23, 2014 · Stefan Koopmanschap
@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.
@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.
But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?
@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...
@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?
Feb 23, 2014 · Stefan Koopmanschap
@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.
@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.
But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?
@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...
@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?
Feb 23, 2014 · Stefan Koopmanschap
@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.
@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.
But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?
@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...
@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?
Feb 23, 2014 · Stefan Koopmanschap
@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.
@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.
But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?
@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...
@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?
Feb 23, 2014 · John Esposito
@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.
@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.
But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?
@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...
@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?
Feb 23, 2014 · John Esposito
@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.
@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.
But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?
@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...
@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?
Feb 23, 2014 · John Esposito
@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.
@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.
But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?
@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...
@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?
Feb 23, 2014 · John Esposito
@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.
@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.
But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?
@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...
@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?
Aug 13, 2012 · James Sugrue
May 21, 2012 · John Esposito
May 21, 2012 · John Esposito
May 17, 2012 · John Esposito
May 02, 2012 · John Esposito
Nothing wrong with the mechanics, of course, but still a little funny because (my silly) stereotype affirms that CoffeeScript lovers love CoffeeScript so much that they never want to see anything but CoffeeScript. Even when actually writing a compiler. :)
Juxtaposing CoffeeScript and C also tickles a sort of funny-bone, because in terms of relative distance-from-the-metal, CoffeeScript and C are opposed, of course, but in terms of relation to a lower-level predecessor language, you might humorously see CoffeeScript->JavaScript as (very roughly) C->assembly (if you're already thinking like dmr).
May 02, 2012 · John Esposito
Nothing wrong with the mechanics, of course, but still a little funny because (my silly) stereotype affirms that CoffeeScript lovers love CoffeeScript so much that they never want to see anything but CoffeeScript. Even when actually writing a compiler. :)
Juxtaposing CoffeeScript and C also tickles a sort of funny-bone, because in terms of relative distance-from-the-metal, CoffeeScript and C are opposed, of course, but in terms of relation to a lower-level predecessor language, you might humorously see CoffeeScript->JavaScript as (very roughly) C->assembly (if you're already thinking like dmr).
Mar 05, 2012 · Eric Genesky
Scale is not an abstraction in the architectural sense, true, so perhaps OP's choice of words was unfortunate. But what he was going for, I think, is a necessary and sufficient condition of 'cloudiness', which might serve as the most useful single index of 'cloud computing'.
It does seem to me that such an index would be helpful, if only as an easy way to cut through the cloudwashing. Is 'scale' useful for this purpose?
Less rhetorically, and more technically: whatever this index turns out to be, it would be very useful to map this index onto full-fledged architectural features. That way the form of the architecture itself will designate X 'cloud' or 'not-cloud'.
My best guess (and I'm not an expert by any stretch) is: anywhere a complex distributed consistency model informs an architecture, that architecture is concerned with scale, and should be considered 'cloudy'. (My thoughts come in great part from this paper.)
But you would be able to construct the architecture->index map much better than I would. (Or maybe someone has done this already, and I just haven't seen it.) Any thoughts?
Mar 05, 2012 · Eric Genesky
Scale is not an abstraction in the architectural sense, true, so perhaps OP's choice of words was unfortunate. But what he was going for, I think, is a necessary and sufficient condition of 'cloudiness', which might serve as the most useful single index of 'cloud computing'.
It does seem to me that such an index would be helpful, if only as an easy way to cut through the cloudwashing. Is 'scale' useful for this purpose?
Less rhetorically, and more technically: whatever this index turns out to be, it would be very useful to map this index onto full-fledged architectural features. That way the form of the architecture itself will designate X 'cloud' or 'not-cloud'.
My best guess (and I'm not an expert by any stretch) is: anywhere a complex distributed consistency model informs an architecture, that architecture is concerned with scale, and should be considered 'cloudy'. (My thoughts come in great part from this paper.)
But you would be able to construct the architecture->index map much better than I would. (Or maybe someone has done this already, and I just haven't seen it.) Any thoughts?
Feb 29, 2012 · briankel
Feb 29, 2012 · Francesco De Vittori
Feb 24, 2012 · John Esposito
Hi Ajya, thanks for the comment! I agree with you -- though my impression is that plenty of developers learned C# first because .NET offers so much leverage.
But this raises an interesting question: do different developers just have different learning styles? that is, do some like starting hard and going easy, and others like easing in before tackling a less hand-holding language like C++? Like Codeacademy vs. Programming from the Ground Up...
Feb 24, 2012 · cjsmith
Feb 14, 2012 · Mr B Loid
Feb 03, 2012 · Mr B Loid
Feb 03, 2012 · John Esposito
Jan 17, 2012 · John Esposito
Jan 11, 2012 · $$ANON_USER$$
Jan 06, 2012 · John Esposito
Dec 29, 2011 · Paul Davis
Dec 29, 2011 · Paul Davis
Dec 29, 2011 · Paul Davis
Dec 29, 2011 · John Esposito
Dec 29, 2011 · John Esposito
Dec 29, 2011 · John Esposito
Dec 27, 2011 · John Esposito
Dec 27, 2011 · Mr B Loid
Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?
What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.
Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?
Dec 27, 2011 · Mr B Loid
Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?
What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.
Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?
Dec 27, 2011 · Mr B Loid
Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?
What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.
Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?
Dec 27, 2011 · Mr B Loid
Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?
What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.
Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?
Dec 27, 2011 · John Esposito
Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?
What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.
Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?
Dec 27, 2011 · John Esposito
Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?
What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.
Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?
Dec 27, 2011 · John Esposito
Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?
What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.
Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?
Dec 27, 2011 · John Esposito
Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?
What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.
Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?
Dec 27, 2011 · Srini Penchikala
Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?
The Wikipedia page on OpenID is pretty good, I think.
Dec 27, 2011 · Srini Penchikala
Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?
The Wikipedia page on OpenID is pretty good, I think.
Dec 27, 2011 · Srini Penchikala
Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?
The Wikipedia page on OpenID is pretty good, I think.
Dec 27, 2011 · Srini Penchikala
Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?
The Wikipedia page on OpenID is pretty good, I think.
Dec 27, 2011 · John Esposito
Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?
The Wikipedia page on OpenID is pretty good, I think.
Dec 27, 2011 · John Esposito
Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?
The Wikipedia page on OpenID is pretty good, I think.
Dec 27, 2011 · John Esposito
Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?
The Wikipedia page on OpenID is pretty good, I think.
Dec 27, 2011 · John Esposito
Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?
The Wikipedia page on OpenID is pretty good, I think.
Dec 22, 2011 · Mr B Loid
You can get the latest IE10 developer preview here, although you'll also need the Windows 8 Developer Preview for that.
MSFT's full IE10 guide for developers is here.
For specific feature support, Try caniuse.com's IE9 vs. IE10 comparison here -- then play with what features and browsers you want to compare.
For a more discursive analysis: Sencha wrote a nice Win8/IE10 first look article here (emphasis on HTML5).
Dec 22, 2011 · John Esposito
You can get the latest IE10 developer preview here, although you'll also need the Windows 8 Developer Preview for that.
MSFT's full IE10 guide for developers is here.
For specific feature support, Try caniuse.com's IE9 vs. IE10 comparison here -- then play with what features and browsers you want to compare.
For a more discursive analysis: Sencha wrote a nice Win8/IE10 first look article here (emphasis on HTML5).
Dec 22, 2011 · John Esposito
That makes sense -- you should be able to use any framework you choose, and then actually choose the framework suited to the project (say, to meet the client's requirements). So maybe rating a framework isn't as useful as comparing and contrasting it with other frameworks (like Socialmention tries to do).
All else being equal, though, don't some frameworks fit individual developers' coding styles better than others? (Not everyone likes ORM, for instance.)
Dec 22, 2011 · John Esposito
That makes sense -- you should be able to use any framework you choose, and then actually choose the framework suited to the project (say, to meet the client's requirements). So maybe rating a framework isn't as useful as comparing and contrasting it with other frameworks (like Socialmention tries to do).
All else being equal, though, don't some frameworks fit individual developers' coding styles better than others? (Not everyone likes ORM, for instance.)
Dec 22, 2011 · John Esposito
That makes sense -- you should be able to use any framework you choose, and then actually choose the framework suited to the project (say, to meet the client's requirements). So maybe rating a framework isn't as useful as comparing and contrasting it with other frameworks (like Socialmention tries to do).
All else being equal, though, don't some frameworks fit individual developers' coding styles better than others? (Not everyone likes ORM, for instance.)
Dec 16, 2011 · Tony Thomas
Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?
I'm not doubting, just wondering how we would know (or conjecture).
Dec 16, 2011 · Tony Thomas
Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?
I'm not doubting, just wondering how we would know (or conjecture).
Dec 16, 2011 · Tony Thomas
Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?
I'm not doubting, just wondering how we would know (or conjecture).
Dec 16, 2011 · Tony Thomas
Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?
I'm not doubting, just wondering how we would know (or conjecture).
Dec 16, 2011 · John Esposito
Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?
I'm not doubting, just wondering how we would know (or conjecture).
Dec 16, 2011 · John Esposito
Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?
I'm not doubting, just wondering how we would know (or conjecture).
Dec 16, 2011 · John Esposito
Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?
I'm not doubting, just wondering how we would know (or conjecture).
Dec 16, 2011 · John Esposito
Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?
I'm not doubting, just wondering how we would know (or conjecture).
Dec 16, 2011 · John Esposito
Dec 13, 2011 · Mr B Loid
Dec 13, 2011 · John Esposito
Dec 10, 2011 · John Esposito
Dec 10, 2011 · John Esposito
Dec 10, 2011 · John Esposito
Dec 09, 2011 · Denzel D.
Dec 06, 2011 · John Esposito
Dec 02, 2011 · Mr B Loid
Dec 02, 2011 · mitchp
Nov 07, 2011 · admin
Oct 31, 2011 · Patrick Wolf
Oct 31, 2011 · John Esposito
Oct 21, 2011 · Gerd Storm
Oct 21, 2011 · mitchp
Sep 29, 2011 · John Esposito