anti-pattern

15 results back to index


pages: 224 words: 48,804

The Productive Programmer by Neal Ford

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

anti-pattern, business process, c2.com, continuous integration, database schema, domain-specific language, Firefox, general-purpose programming language, knowledge worker, side project, type inference, web application, William of Occam

Some hard-fought knowledge about software development is not intuitive. The idea that you can design the entire software up front, and then just transcribe it seems logical, but it doesn’t work in the real world of constant change. Fortunately, a giant catalog of nonintuitive software lore exists in the Anti Patterns catalog (http://c2.com/cgi/wiki? AntiPatternsCatalog). This is the ancient lore of software. Rather than gnashing your teeth in frustration when your boss is forcing you to use a library of subquality code, point out to him that he’s falling into the “Standing on the Shoulder of Midgets” anti pattern, and he’ll see that you aren’t the only one who thinks it’s a bad idea. Understanding the existing software lore provides great resources when you are being asked to do something that you know in your gut is the wrong thing to do, and yet some managertype is forcing the issue.

We know all sorts of ways to deal with code: diff to compare versions, refactoring, robust testing libraries. Why would we give all the accumulated knowledge of what we know about code just for the siren song of some elaborate tool? NOTE Pay attention to the evolution of your tools. Un-Choosing the Wrong Tools As important (or perhaps even more so) than choosing the right tools is rejecting bad tools. In fact, an anti-pattern exists that describes this: boat anchor. A boat anchor is a tool that you are forced to use even though it is ridiculously ill-suited for the job at hand. Frequently, this boat anchor costs a vast amount of money, increasing the political pressure to use it for every situation. For a tortured but depressingly accurate metaphor, imagine that a carpenter was forced to use a sledge hammer (undoubtably powerful) for driving nails.

They got their code in the standard place, and we got to use the tool best suited for our work. Fight internal feature creep and boat anchors While vendors are the pushers of accidental complexity, it grows within organizations as well. Boat anchors don’t have to be external tools; they are often existing, homegrown headaches. Lots of projects are saddled with inappropriate internal frameworks and tools (victims of the Standing on the Shoulders of Midgets anti-pattern). Business users request “nice to have” functionality without understanding the orders of magnitude of difficulty involved. Developers, architects, and tech leads must make users and management understand the cost of complexity incurred by using inappropriate tools, libraries, and frameworks. Being saddled with an inappropriate tool may seem like a minor thing (especially to nondevelopers), but it can have a huge impact on the overall productivity of developers.

 

pages: 349 words: 114,038

Culture & Empire: Digital Revolution by Pieter Hintjens

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

4chan, airport security, anti-communist, anti-pattern, barriers to entry, Bill Duvall, bitcoin, blockchain, business intelligence, business process, Chelsea Manning, clean water, congestion charging, correlation does not imply causation, cryptocurrency, Debian, Edward Snowden, failed state, financial independence, Firefox, full text search, German hyperinflation, global village, GnuPG, Google Chrome, greed is good, Hernando de Soto, hiring and firing, informal economy, invisible hand, James Watt: steam engine, Jeff Rulifson, Julian Assange, Kickstarter, M-Pesa, mutually assured destruction, Naomi Klein, national security letter, new economy, New Urbanism, Occupy movement, offshore financial centre, packet switching, patent troll, peak oil, pre–internet, private military company, race to the bottom, reserve currency, RFC: Request For Comment, Richard Stallman, Satoshi Nakamoto, security theater, Skype, slashdot, software patent, spectrum auction, Steve Crocker, Steve Jobs, Steven Pinker, The Wealth of Nations by Adam Smith, The Wisdom of Crowds, trade route, transaction costs, union organizing, web application, WikiLeaks, Y2K, zero day, Zipf's Law

Aggressive groups, like cults, can break down a person's mind by forcing out all independence and replacing it with a synthetic groupthink. People who undergo such treatment become compliant and accept authority without question. There is a whole dark science of turning intelligent individuals into accepting morons, simply through the manipulation of their social context. For more on this, see "Social Anti-Patterns" in “Spheres of Light”. Happily, in my experience, this process also works in reverse. When we can construct our own lives, we generally become happier, more productive, and more discerning. The easy dogmas of the past are broken down and a form of wisdom based on uncovering objective truths takes their place. Like planting a forest tree by tree, it's a slow and almost invisible process and one that is, for me, absolutely key to understanding digital society.

Self-Organization Some people like to be told what to do. The best contributors and teams choose their own tasks. A successful community recognizes problems and organizes itself to solve them. Further, it does that faster and more accurately than any top-down management structure. This means the community should accept contributions in any area, without limit. Top-down task assignment is an anti-pattern with many weaknesses. It makes it impossible for individuals to act when they recognize new problems. It creates fiefdoms where work and the necessary resources belong to specific people. It creates long communication chains that can't react rapidly. It requires layers of managers just to connect decision-makers with those doing the work. TIP: Write rules to raise the quality of work and to explicitly allow anyone to work on anything they find interesting.

Power structures are like liquid cement; they harden and stop people from moving around as they need to. Any structure defends itself. Tolerance A diverse group has conflicting opinions, and a healthy group has to embrace and digest these conflicts. Critics, iconoclasts, vandals, spies, and trolls keep a group on its toes. They can be a catalyst for others to stay involved. Wikipedia thrives thanks to, not in spite of, those who click Edit to make a mess of articles. It's a classic anti-pattern to suppress minority ideas and views on the basis that they are "dangerous." This inevitably means suppressing new ideas as well. The logic is usually that group coherence is more important than diversity. What then happens is that mistakes aren't challenged, and get solidified into policy. In fact, the group can be more important than the results, if it is diverse and open to arguments. This is a difficult lesson that applies to broad society as well: there are no dangerous opinions, only dangerous responses.

 

pages: 372 words: 67,140

Jenkins Continuous Integration Cookbook by Alan Berg

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

anti-pattern, continuous integration, Debian, en.wikipedia.org, Firefox, job automation, performance metric, revision control, web application, x509 certificate

The includes override specific file types under the src directory. Depending on the type of frameworks used in your projects, the range of includes will change. For information on customizing RATs for specific license types, visit: http://incubator.apache.org/rat/apache-rat-plugin/examples/custom-license.html There's more... Here are a few more useful tips to review: Multiple approaches and anti-patterns There were multiple approaches to configuring the Jenkins Job. You could avoid copying the RATs report file by fixing its location in the Maven plugins configuration. This has the advantage of avoiding a copying action. You could also use the Multiple SCM plugin (https://wiki.jenkins-ci.org/display/JENKINS/Multiple+SCMs+Plugin) to first copy the source code into the workspace. You should also consider splitting into two Jobs, and then pointing the RATs Job at the source codes workspace.

In the plugins directory, under the Jenkins workspace, you will find an HTML file for help with the configuration of Google plugins, named /plugins/gcal/help-projectConfig.html. Replace the contents with the following: <div> <p> Add your local comments here: </p> </div> After restarting the Jenkins server, visit the plugin configuration /configure. You will now see the new content. This example is an anti-pattern. If you need to change content for local needs, it is much better to work with the community, adding to the Jenkins SCM, so everyone can see and improve. You will be told immediately that your content is not internationalized. It needs to be translated into the languages that Jenkins supports natively. Luckily, at the bottom of every Jenkins page, there is a link that volunteers can use to upload translations.

To include external detectors, you added an extra line to FindBugs' Maven configuration: <pluginList> http://downloads.sourceforge.net/project/fb-contrib/Current/ fb-contrib-4.6.1.jar </pluginList> It is worth visiting SourceForge to check for the most up-to-date version of the detectors. Currently, it is not possible to use Maven's dependency management to pull in the detectors through from a repository, though this might change. In this recipe, you have added a Java class to trigger the new bug detection rules. The anti-pattern is the unnecessary line with the creation of the answer object before the return. It is more succinct to return the object anonymously, for example: Return "This is the answer"; The ant-pattern triggers the USBR_UNNECESSARY_STORE_BEFORE_RETURN pattern, which is described on the home page of the fb-contrib project. See also Finding bugs with FindBugs Finding security defects with FindBugs Activating more PMD rulesets Finding security defects with FindBugs In this recipe, you will use FindBugs to discover a security flaw in a Java Server Page and some more security defects in a defective Java class.

 

pages: 201 words: 63,192

Graph Databases by Ian Robinson, Jim Webber, Emil Eifrem

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Amazon Web Services, anti-pattern, bioinformatics, corporate governance, create, read, update, delete, data acquisition, en.wikipedia.org, linked data, loose coupling, Network effects, recommendation engine, semantic web, sentiment analysis, social graph, software as a service, SPARQL, web application

Data Modeling with Graphs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Models and Goals The Property Graph Model Querying Graphs: An Introduction to Cypher Cypher Philosophy START MATCH RETURN Other Cypher clauses 25 26 27 27 29 29 30 30 iii A Comparison of Relational and Graph Modeling Relational Modeling in a Systems Management Domain Graph Modeling in a Systems Management Domain Testing the Model Cross-Domain Models Creating the Shakespeare Graph Beginning a Query Declaring Information Patterns to Find Constraining Matches Processing Results Query Chaining Common Modeling Pitfalls Email Provenance Problem Domain A Sensible First Iteration? Second Time’s the Charm Evolving the Domain Avoiding Anti-Patterns Summary 30 31 34 36 37 40 42 42 44 45 46 46 47 47 49 51 54 55 4. Building a Graph Database Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Data Modeling Describe the Model in Terms of Your Application’s Needs Nodes for Things, Relationships for Structure Fine-Grained Versus Generic Relationships Model Facts as Nodes Represent Complex Value Types as Nodes Time Iterative and Incremental Development Application Architecture Embedded Versus Server Clustering Load Balancing Testing Test-Driven Data Model Development Performance Testing Capacity Planning Optimization Criteria Performance Redundancy Load 57 57 59 59 60 64 64 67 68 68 73 74 76 76 82 86 87 87 90 90 5.

START email = node:email(id = '11') MATCH (email)<-[f:FORWARD_OF*]-() RETURN count(f) The above query starts at the given email and then matches against all incoming FOR WARD_OF relationships to any depth. These relationships are bound to an identifier f. To calculate the length of the email chain, we count the number of FORWARD_OF relationships bound to f using Cypher’s count function. In this example, we see the original email has been forwarded twice: +----------+ | count(f) | +----------+ | 2 | +----------+ 1 row Avoiding Anti-Patterns In the general case, don’t encode entities into relationships. Use relationships to convey semantics about how entities are related, and the quality of those relationships. Domain entities aren’t always immediately visible in speech, so think carefully about the nouns you’re actually dealing with. It’s also important to realize that graphs are a naturally additive structure. It’s quite natural to add facts in terms of domain entities and how they interrelate using new nodes and new relationships, even if it feels like you’re flooding the database with a great deal of painstaking data.

 

Exploring ES6 - Upgrade to the next version of JavaScript by Axel Rauschmayer

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

anti-pattern, domain-specific language, en.wikipedia.org, Firefox, Google Chrome, MVC pattern, web application, WebSocket

Thus, we can convert a jQuery deferred to an ES6 Promise via Promise.resolve(): Promise.resolve( jQuery.ajax({ url: 'somefile.html', type: 'GET' })) .then(function (data) { console.log(data); }) .catch(function (reason) { console.error(reason); }); ²⁷https://github.com/matthew-andrews/denodeify/ ²⁸http://api.jquery.com/category/deferred-object/ ²⁹https://github.com/kriskowal/q/wiki/Coming-from-jQuery Promises for asynchronous programming 476 25.17 Further reading [1] “Promises/A+³⁰”, edited by Brian Cavalier and Domenic Denicola (the de-facto standard for JavaScript Promises) [2] “JavaScript Promises: There and back again³¹” by Jake Archibald (good general intro to Promises) [3] “Promise Anti-Patterns³²” by Tao of Code (tips and techniques) [4] “Promise Patterns³³” by Forbes Lindesay [5] “The Revealing Constructor Pattern³⁴” by Domenic Denicola (this pattern is used by the Promise constructor) ³⁰http://promisesaplus.com/ ³¹http://www.html5rocks.com/en/tutorials/es6/promises/ ³²http://taoofcode.net/promise-anti-patterns/ ³³https://www.promisejs.org/patterns/ ³⁴http://domenic.me/2014/02/13/the-revealing-constructor-pattern/ VI Miscellaneous 26. Unicode in ES6 This chapter explains the improved support for Unicode that ECMAScript 6 brings. For a general introduction to Unicode, read “Unicode and JavaScript¹” (a chapter in “Speaking JavaScript”). 26.1 Unicode is better supported in ES6 There are three areas in which ECMAScript 6 has improved support for Unicode: • Unicode escapes for code points beyond 16 bits: \u{···} Can be used in identifiers, string literals, template literals and regular expression literals.

Also similarly to functions, the identifier of a class expression is only visible within the expression: const MyClass = class Me { getClassName() { return Me.name; } }; let inst = new MyClass(); console.log(inst.getClassName()); // Me console.log(Me.name); // ReferenceError: Me is not defined 16.2.2 Inside the body of a class definition A class body can only contain methods, but not data properties. Prototypes having data properties is generally considered an anti-pattern, so this just enforces a best practice. 16.2.2.1 constructor, static methods, prototype methods Let’s examine three kinds of methods that you often find in class definitions. class Foo { constructor(prop) { this.prop = prop; } static staticMethod() { return 'classy'; } prototypeMethod() { return 'prototypical'; Classes 215 } } let foo = new Foo(123); The object diagram for this class declaration looks as follows.

 

pages: 540 words: 103,101

Building Microservices by Sam Newman

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

airport security, Amazon Web Services, anti-pattern, business process, call centre, continuous integration, create, read, update, delete, defense in depth, Edward Snowden, index card, information retrieval, Infrastructure as a Service, inventory management, job automation, load shedding, loose coupling, platform as a service, premature optimization, pull request, recommendation engine, social graph, software as a service, the built environment, web application, WebSocket, x509 certificate

A good rule of thumb is that you probably want an order of magnitude more tests as you descend the pyramid, but the important thing is knowing that you do have different types of automated tests and understanding if your current balance gives you a problem! I worked on one monolithic system, for example, where we had 4,000 unit tests, 1,000 service tests, and 60 end-to-end tests. We decided that from a feedback point of view we had way too many service and end-to-end tests (the latter of which were the worst offenders in impacting feedback loops), so we worked hard to replace the test coverage with smaller-scoped tests. A common anti-pattern is what is often referred to as a test snow cone, or inverted pyramid. Here, there are little to no small-scoped tests, with all the coverage in large-scoped tests. These projects often have glacially slow test runs, and very long feedback cycles. If these tests are run as part of continuous integration, you won’t get many builds, and the nature of the build times means that the build can stay broken for a long period when something does break.

With the tests that run as part of the pipeline for a specific service, the sensible starting point is that the team that owns that service should write those tests (we’ll talk more about service ownership in Chapter 10). But if we consider that we might have multiple teams involved, and the end-to-end-tests step is now effectively shared between the teams, who writes and looks after these tests? I have seen a number of anti-patterns caused here. These tests become a free-for-all, with all teams granted access to add tests without any understanding of the health of the whole suite. This can often result in an explosion of test cases, sometimes resulting in the test snow cone we talked about earlier. I have seen situations where, because there was no real obvious ownership of these tests, their results get ignored. When they break, everyone assumes it is someone else’s problem, so they don’t care whether the tests are passing.

 

pages: 153 words: 27,424

REST API Design Rulebook by Mark Masse

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

anti-pattern, conceptual framework, create, read, update, delete, data acquisition, database schema, hypertext link, information retrieval, web application

Rule: CRUD function names should not be used in URIs URIs should not be used to indicate that a CRUD[22] function is performed. URIs should be used to uniquely identify resources, and they should be named as described in the rules above. As discussed in Request Methods, HTTP request methods should be used to indicate which CRUD function is performed. For example, this API interaction design is preferred: DELETE /users/1234 The following anti-patterns exemplify what not to do: GET /deleteUser?id=1234 GET /deleteUser/1234 DELETE /deleteUser/1234 POST /users/1234/delete * * * [20] Web Resource Modeling Language (WRML) was introduced in WRML [21] http://tools.ietf.org/html/draft-gregorio-uritemplate. [22] CRUD is an acronym that stands for create, read, update, delete—the four standard, storage-oriented functions. URI Query Design This section provides rules relating to the design of URI queries.

 

Programming Android by Zigurd Mednieks, Laird Dornin, G. Blake Meike, Masumi Nakamura

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

anti-pattern, business process, conceptual framework, create, read, update, delete, database schema, Debian, domain-specific language, en.wikipedia.org, Google Earth, interchangeable parts, iterative process, loose coupling, MVC pattern, revision control, RFID, web application

The implementation might have bugs, but at least addTextChangedListener will never be passed, say, an object intended to respond to network events. That is what polymorphism is all about. It is worth mentioning one particular antipattern in this context, because it is so common. Many developers find anonymous classes to be a verbose and clumsy way of essentially passing a pointer to a function. In order to avoid using them, they skip the messenger object altogether, like this: // !!! Anti-pattern warning public class MyModel implements TextWatcher { public MyModel(TextView textBox) { textBox.addTextChangedListener(this); } public void afterTextChanged(Editable s) { handleTextChange(s); } public void beforeTextChanged( CharSequence s, int start, int count, int after) { } public void onTextChanged( CharSequence s, int start, int count, int after) { } void handleTextChange(Editable s) { // do something with s, the changed text. } } Sometimes this approach makes sense.

On the other hand, if (as the name MyModel suggests) the class will be used broadly and in a wide variety of circumstances, eliminating the messenger classes breaks encapsulation and limits extension. Obviously, it’s going to be messy to extend this implementation to handle input from a second TextBox that requires different behavior. Nearly as bad, though, is something called interface pollution, which happens when this idea is taken to an extreme. It looks like this: // !!! Anti-pattern ALERT! public class MyModel implements TextWatcher, OnKeyListener, View.OnTouchListener, OnFocusChangeListener, Button.OnClickListener { // .... } Code like this is seductively elegant, in a certain way, and fairly common. Unfortunately, though, MyModel is now very tightly coupled to every one of the events it handles. As usual, there are no hard and fast rules about interface pollution. There is, as already noted, lots of working code that looks just like this.

 

pages: 655 words: 141,257

Programming Android: Java Programming for the New Generation of Mobile Devices by Zigurd Mednieks, Laird Dornin, G. Blake Meike, Masumi Nakamura

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

anti-pattern, business process, conceptual framework, create, read, update, delete, database schema, Debian, domain-specific language, en.wikipedia.org, Google Earth, interchangeable parts, iterative process, loose coupling, MVC pattern, revision control, RFID, web application

The implementation might have bugs, but at least addTextChangedListener will never be passed, say, an object intended to respond to network events. That is what polymorphism is all about. It is worth mentioning one particular antipattern in this context, because it is so common. Many developers find anonymous classes to be a verbose and clumsy way of essentially passing a pointer to a function. In order to avoid using them, they skip the messenger object altogether, like this: // !!! Anti-pattern warning public class MyModel implements TextWatcher { public MyModel(TextView textBox) { textBox.addTextChangedListener(this); } public void afterTextChanged(Editable s) { handleTextChange(s); } public void beforeTextChanged( CharSequence s, int start, int count, int after) { } public void onTextChanged( CharSequence s, int start, int count, int after) { } void handleTextChange(Editable s) { // do something with s, the changed text. } } Sometimes this approach makes sense.

On the other hand, if (as the name MyModel suggests) the class will be used broadly and in a wide variety of circumstances, eliminating the messenger classes breaks encapsulation and limits extension. Obviously, it’s going to be messy to extend this implementation to handle input from a second TextBox that requires different behavior. Nearly as bad, though, is something called interface pollution, which happens when this idea is taken to an extreme. It looks like this: // !!! Anti-pattern ALERT! public class MyModel implements TextWatcher, OnKeyListener, View.OnTouchListener, OnFocusChangeListener, Button.OnClickListener { // .... } Code like this is seductively elegant, in a certain way, and fairly common. Unfortunately, though, MyModel is now very tightly coupled to every one of the events it handles. As usual, there are no hard and fast rules about interface pollution. There is, as already noted, lots of working code that looks just like this.

 

pages: 209 words: 54,638

Team Geek by Brian W. Fitzpatrick, Ben Collins-Sussman

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

anti-pattern, barriers to entry, cognitive dissonance, Dean Kamen, en.wikipedia.org, fear of failure, Paul Graham, Richard Stallman, Silicon Valley, Steve Jobs, web application

” — Vint Cerf “I’ve been working with engineers for over 30 years, and in that time I’ve learned that engineering is as much about people as it is science and technology, but most engineers put little or no effort into understanding how to work with others. If you want to be more effective and efficient at creating and innovating, then this book is for you.” — Dean Kamen “Ben and Fitz have assembled an amazing collection of patterns and anti-patterns for software development teams to consider. This book is for anyone struggling with understanding how to make such a team more productive—for the code wranglers themselves, for their managers, and for everyone in orbit around them. It puts down on paper many of the things innate to great open source developers. I wish I’d had this book years ago.” — Brian Behlendorf “Software Development is a team sport.

 

Sass and Compass for Designers by Ben Frain

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

anti-pattern, Firefox, Steve Jobs

If your humble author has done even a half decent job, you should have gained an understanding of most of the major functionality and techniques available when using Sass and Compass to author style sheets. Just be mindful that although we have these skills and techniques at our disposal, this doesn't necessarily mean they are right to use all the time. Practically, we have already considered that things such as over-nesting rules can produce anti-patterns in our generated code. In the same vein, consider whether other practices that are now more easily achievable with Sass and Compass are actually the right choice. In-lining a 1 MB image as a data URI in your CSS wouldn't be a smart move, for example. I know you'll make the right choices. With that fatherly advice squared away, my primary wish is that you now feel empowered and not intimidated by all that Sass and Compass has to offer.

 

pages: 420 words: 79,867

Developing Backbone.js Applications by Addy Osmani

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Airbnb, anti-pattern, create, read, update, delete, database schema, Firefox, full text search, Google Chrome, Khan Academy, loose coupling, MVC pattern, node package manager, pull request, side project, single page application, web application

In Thorax, this can particularly useful in conjunction with the collection helper which generates a view class (with a model property) for each model in the collection. An example template: {{#collection kittens tag="ul"}} <li>{{name}}</li> {{/collection}} And the corresponding view class: Thorax.View.extend({ events: { 'click li': function(event) { var kitten = $(event.target).model(); console.log('Clicked on ' + kitten.get('name')); } }, kittens: new Thorax.Collection(...), template: ... }); A common anti-pattern in Backbone applications is to assign a className to a single view class. Consider using the data-view-name attribute as a CSS selector instead, saving CSS classes for things that will be used multiple times: [data-view-name="child"] { } Thorax Resources No Backbone related tutorial would be complete without a todo application. A Thorax implementation of TodoMVC is available, in addition to this far simpler example composed of this single Handlebars template: {{#collection todos tag="ul"}} <li{{#if done}} class="done"{{/if}}> <input type="checkbox" name="done"{{#if done}} checked="checked"{{/if}}> <span>{{item}}</span> </li> {{/collection}} <form> <input type="text"> <input type="submit" value="Add"> </form> and the corresponding JavaScript: var todosView = Thorax.View({ todos: new Thorax.Collection(), events: { 'change input[type="checkbox"]': function(event) { var target = $(event.target); target.model().set({done: !!

 

pages: 315 words: 85,791

Technical Blogging: Turn Your Expertise Into a Remarkable Online Presence by Antonio Cangiano

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Albert Einstein, anti-pattern, bitcoin, bounce rate, cloud computing, en.wikipedia.org, John Gruber, Lean Startup, Network effects, revision control, search engine result page, slashdot, software as a service, web application

Reason to read it: To stay up-to-date and keep a pulse on the Ruby ecosystem. http://daringfireball.net: News and opinions about Apple by an unrepentant advocate of Apple products. Reason to read it: It provides fresh insight, interesting controversy, and news about Apple and its competitors delivered by an established community pundit. http://thedailywtf.com: Daily examples of bad programming. Reason to read it: To learn more about anti-patterns in programming, and for the amusement. http://igvita.com: HOWTO articles on cutting-edge open source technologies. Reason to read it: To learn how to use some of the coolest technologies around and apply them to real-world problems. http://sethgodin.typepad.com: Marketing ideas and opinions. Reason to read it: To improve your marketing skills with the aid of a leader in the marketing world via thought-provoking ideas and insight.

 

pages: 1,025 words: 150,187

ZeroMQ by Pieter Hintjens

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

anti-pattern, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, factory automation, fear of failure, finite state, Internet of things, iterative process, premature optimization, profit motive, pull request, revision control, RFC: Request For Comment, Richard Stallman, Skype, smart transportation, software patent, Steve Jobs, Valgrind, WebSocket

Some widely used models, despite being the basis for entire industries, are fundamentally broken, and shared state concurrency is one of them. Code that wants to scale without limit does it like the Internet does, by sending messages and sharing nothing except a common contempt for broken programming models. You should follow some rules to write happy multithreaded code with ØMQ: You must not access the same data from multiple threads. Using classic MT techniques like mutexes is an anti-pattern in ØMQ applications. The only exception to this is a ØMQ context object, which is threadsafe. You must create a ØMQ context for your process, and pass that to all threads that you want to connect via inproc sockets. You may treat threads as separate tasks with their own context, but these threads cannot communicate over inproc. However, they will be easier to break into standalone processes afterwards.

 

pages: 834 words: 180,700

The Architecture of Open Source Applications by Amy Brown, Greg Wilson

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

8-hour work day, anti-pattern, bioinformatics, c2.com, cloud computing, collaborative editing, combinatorial explosion, computer vision, continuous integration, create, read, update, delete, Debian, domain-specific language, en.wikipedia.org, finite state, Firefox, friendly fire, linked data, load shedding, locality of reference, loose coupling, MVC pattern, premature optimization, recommendation engine, revision control, side project, Skype, slashdot, social web, speech recognition, the scientific method, The Wisdom of Crowds, web application, WebSocket

The lobby module, for displaying and allowing setup of games on the multiplayer server. The "play game" module that controls the main gameplay. The "play game" module and the main display module are the largest within Wesnoth. Their purpose is the least well defined, as their function is ever-changing and thus difficult to have a clear specification for. Consequently, the modules has often been in danger of suffering from the Blob anti-pattern over the program's history—i.e., becoming huge dominant segments without well-defined behaviors. The code in the display and play game modules are regularly reviewed to see if any of it can be separated into a module of its own. There are also ancillary features that are part of the overall project, but are separate from the main program. This includes a multiplayer server that facilitates multiplayer network games, as well as a content server that allows users to upload their content to a common server and share it with others.