Group items tagged

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.

commity Kernighana, Ritchieho, Bournea .. The goal of this project is to create a git repository representing the Unix source code history, starting from the 1970s and ending in the modern time. To fulfill this goal the project brings data from early snapshots, repositories, and primary research. The project aims to put in the repository as much metadata as possible, allowing the automated analysis of Unix history. The following table illustrates the type of material that can be gathered and integrated into the repository.

if you don't pass a header, by default Ruby will pass the header that will tell the external service that your app is ok with a Gzipped response (which is obviously wrong)

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).

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.

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 :)

How secure are your Ruby projects? Scan Gemfile.lock for vulnerabilities, take action, and ship secure apps!

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

However, ADB found that a former employee of Gemalto had prepared the tender document. A fresh bidding process is expected to be announced in the future.

It all sounds so straightforward: Put your code up on GitHub or start/join a project at the Apache Software Foundation (ASF), build a community of like-minded individuals, start a company, take in some funding, and then IPO. Or maybe not. One thing is certain: Running an open source company has unique challenges and opportunities.

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.

There's no such thing as an anonymous programmer: your coding style can unmask you, according to research led by Drexel University Comp. Sci. PhD student Aylin Caliskan-Islam. In work that has serious implications for anyone believing their open source project contributions are anonymous, the researchers find that as many as 95 per cent of contributors to a decent-sized code base can be identified.

the spirit of modern society is one of intense equality, which is a torture in terms of envy, for when egalitarian ambitions circulate in societies that tell themselves that anyone can do anything, the experience of envy goes into over-drive. We don't envy everyone, we do so only when we think their advantages are within our reach. So when almost everything feels like it could be ours (but a lot never can be), the opportunities for envy grow dangerously large.