Group items tagged

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: - Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; - Have a clean contract with the underlying operating system, offering maximum portability between execution environments; - Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; - Minimize divergence between development and production, enabling continuous deployment for maximum agility; - And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

North encourages an agile, content-first, approach to product development and a mobile-first, in-browser, system based approach to design and development.

In this article, author talks about how to improve the accuracy of software development effort estimations. He suggests to use relevant historical data improve estimation accuracy and to avoid early estimates based on incomplete information. He also discusses how to measure and predict productivity in software projects.

Workplace stress costs the U.S economy hundreds of billions of dollars per year and is prevalent across all types of organizations and workplaces. If you have adopted or are in the process of adopting the devops methodology and culture, chances are your software developers are burning out as well.

Cognitive dissonance is the most often cited reason for claims for independent testing teams. IF the tester is part of the development team that created the product, then he will be biased to confirm the product is working.

personally think that developers shouldn't care about code beauty, because that's not their job. Instead, they should focus on creating great products, which is infinitely more satisfying. Code Fashion What defines beauty in code? Just like for clothes, opinions on the subject may vary. Each year, we find new trend-setters, like Jeff Atwood, Martin Fowler, or Eric Evans. They offer convincing arguments to explain why pattern A is better than pattern B. Until someone else publishes a book, explaining that pattern C is much, much better

analyza a suhrn mnohych biometrickych projektov

I'm not going to be talking about the third step of the TDD cycle. Refactoring code that's in development and not currently running on production is something you must absolutely do. Work clean, and write clean code. What we're talking about is changes to existing, running code.

I've never met a developer who complained about code getting faster or taking up less RAM. In Ruby, memory is especially important, yet few developers know the ins-and-outs of why their memory use goes up or down as their code executes.

mozno trosku bulvarny titulok tykajuci sa beznej http komunikacie, ale je zaujimave to vidiet, ako lahko sa da v tomto svete modulov prist k nestastiu :) myslim,ze sa to rovnako tyka ruby gemov, chef receptov a vsetkeho dalsieho, co obycajne automatizovane tahame cez http..

ten blogpost je o niecom uplne inom (mikroformatoch), ale je tam zaujimavy kapitolka o tom, ze sa im email ako nastroj na vymenu informacii a brainstorming neosvedcil: Perhaps the most important is that as a community we are far more efficiently productive using just IRC and the wiki, than any amount of use of email. In fact, the microformats drafts that were developed wtih the most email (e.g. hAudio) turned out to be the hardest to follow and discuss (too many long emails), and sadly ended up lacking the simplicity that real world publishers wanted (e.g. last.fm).

Need-to-know (like other security measures) can be misused by persons who wish to refuse others access to information they hold in an attempt to increase their personal power or prevent unwelcome review of their work.

A few years ago, I took on a freelance project to implement an Internet Explorer component in C++. I was billing a healthy hourly rate on other projects at the time, but this particular client insisted on a fixed price. In a bout of temporary insanity, I made an exception.... Every developer knows that accurate software estimation is not possible even when perfect information is available about project requirements (i.e. practically never).....

podobne nazory na estimate trvania taskov som cez vikend cital aj v tomto clanku https://techcrunch.com/2016/12/11/death-to-jira/ , odhady veru nie su easy

Z toho clanku "death to JIRA" vypichujem: For some reason many companies today seem to be terrified of the prospect of writing more than a couple of paragraphs of clear and simple prose. But a well-written 8-page document can define the nuances of a complicated system far better than a whole cumbersome flotilla of interlinked JIRA tickets. ... Feature planning is about communication. JIRA is fundamentally a terrible way to communicate the requirements of a complex system. Words in a row, if written well, will always be better. A v dost vela veciach suhlasim.

PostgreSQL is an open source multi-purpose relational database system which is widely used throughout the world. It is one huge system with the integrated subsystems, each of which has a particular complex feature and works with each other cooperatively. Although understanding of the internal mechanism is crucial for both administration and integration using PostgreSQL, its hugeness and complexity prevent it.

Web/app projects these days often have many distributed parts. It's not uncommon for groups to use the right tool for the job. The right tools are often something like the choice below. Redis for queuing, and caching. Elastic Search for searching, and log stash. Influxdb or RRD for timeseries. S3 for an object store. PostgreSQL for relational data with constraints, and validation via schemas. Celery for job queues. Kafka for a buffer of queues or stream processing. Exception logging with PostgreSQL (perhaps using Sentry) KDB for low latency analytics on your column oriented data. Mongo/ZODB for storing documents JSON (or mangodb for /dev/null replacement) SQLite for embedded. Neo4j for graph databases. RethinkDB for your realtime data, when data changes, other parts 'react'. ... For all the different nodes this could easily cost thousands a month, require lots of ops knowledge and support, and use up lots of electricity. To set all this up from scratch could cost one to four weeks of developer time depending on if they know the various stacks already. Perhaps you'd have ten nodes to support. Could you gain an ops advantage by using only PostgreSQL?

I was playing a bit with OrientDB because the licensing model is not that pricey as for Neo4j. Anyway, after having really bad experience (http://orientdbleaks.blogspot.com/) I returned back to CouchDB, although it's not a graph db. But while I was searching for more data, I found this: http://www.aptuz.com/blog/is-postgres-nosql-database-better-than-mongodb/ and this: https://www.arangodb.com/2015/10/benchmark-postgresql-mongodb-arangodb/ so I'm pondering with an idea to give postgres(no)sql a chance :)

They have developed a new substance called Lumicyano that makes it possible to highlight fingerprints directly, more rapidly and at a lower cost, avoiding the cumbersome processes required until now.

The first metric I was wondering about is the distribution of gems in Gemfiles. How many gems does a common Ruby developer use in their projects? The numbers are somewhat expected: the average number of gems per Gemfile is 113.08 with the standard deviation of 52.19.... The next question I had was how many of those gems contain at least one vulnerability? The numbers are staggering! 1,333 Gemfiles, or 66% of the total, are affected! I definitely didn't expect that two thirds of all projects would contain at least one publicly known vulnerability.

the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors. Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.