If you have used indeed.com before, you may know that for the keywords you look for, it returns a traditional search results as long as multiple search refinement options on the left side of screen.
For example, searching for keyword "designer", the refinement options are:
Salary Estimate
$40,000+ (45982)
$60,000+ (29795)
$80,000+ (15966)
$100,000+ (6896)
$120,000+ (2828)
Title
Floral Design Specialist (945)
Hair Stylist (817)
GRAPHIC DESIGNER (630)
Hourly Associates/Co-managers (589)
Web designer (584)
more »
Company
Kelly Services (1862)
Unlisted Company (1133)
CyberCoders Engineering (1058)
Michaels Arts & Crafts (947)
ULTA (818)
Elance (767)
Location
New York, NY (2960)
San Francisco, CA (1633)
Chicago, IL (1184)
Houston, TX (1057)
Seattle, WA (1025)
more »
Job Type
Full-time (45687)
Part-time (2196)
Contract (8204)
Internship (720)
Temporary (1093)
How does it gather statistics information so quickly (e.g. the number of job offers in each salary range). Looks like the refinement options are created in realtime since minor keywords load fast too.
Is there a specific SQL technique to create such feature? Or is there a manual on the web explaining the tech behind this?
The technology used in Indeed.com and other search engines is known as inverted indexing which is at the core of how search engines work (e.g Google). The filtering you refer to ("refinement options") are known as facets.
You can use Apache Solr, a full-fledged search server built using Lucene and easily integrable into your application using its RESTful API. Comes out-of-the-box with several features such as faceting, caching, scaling, spell-checking, etc. Is also used by several sites such as Netflix, C-Net, AOL etc. - hence stable, scalable and battle-tested.
If you want to dig deep into facet based filtering works, lookup Bitsets/Bitarrays and is described in this article.
Why do you think that they load "too fast"? They certainly have nice, scaled architecture, they use caching for sure, they might be using some denormalized datastore to accelerate some computations and queries.
Take a look at google and number of web pages worldwide - you also think that google works too fast?
In addition to what Mios said and as Daimon mentioned it does use a denormalized doc store. Here is a link to Indeed's tech talk about its docstore
http://engineering.indeed.com/blog/2013/03/indeedeng-from-1-to-1-billion-video/
Also another related article on their Engineering blog:
http://engineering.indeed.com/blog/2013/10/serving-over-1-billion-documents-per-day-with-docstore-v2/
Examples of things that are excluded: mechanical engineering, chemical engineering, industrial design.
I've struggled with
Technology
Hi Tech
Computer Science
EE
But I can't come up with an overarching term that is generally understood by everyone that means all of SW, FW and HW combined. Any suggestions?
How about "System"?
Vertical solution/system maybe. Turnkey works too, but I tend to think of that as also meaning "drop in and go" while a vertical solution may still require a lot of implementation effort.
If you're speaking relative to a particular product or project, I think you're looking for some variant on "stack" or "platform". The technology stack, the project stack, etc. If you're looking for a word that generally indicates the entire sphere of hardware, firmware, and software technology, I think you're better off listing them out like that. If you're free to editorialize, you might speak of the things they have in common, like bits & bytes or circuits & logic.
Here you go:
Computerware
Noun
All hardware and software components of a computer system.
The StrawRaspBananaBerry pie mini computer is a fully open source
device as all computerware is under a GPL 2.0 license.
https://www.urbandictionary.com/define.php?term=computerware
"Box"? ;-P
Could it not be "system"? Or "device" or something similar?
Iphone ? just kidding The proper term for an end to end solution is "turnkey solution". I guess that is what you are looking for a representation of a Complete Solution.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So many buzzwords. Not sure if I need to start playing BS Bingo or not. And I'm not trying to be cynical. But I've heard many people with these various titles. There never seems to be a clear delineation between the three. Or there's a lot of domain crossover between the three. Actually, another I've seen while looking around here on Stackoverflow has been "Solutions Architect" as well. But that one doesn't seem to be so prevalent in other places.
There are questions here and there with vague answers. But I'd like definative answers to this. Please assume I'm still relatively new to software stuff and that I'm trying to map out a career path.
Oh, and please be gentle folks; this most definitely is not a duplicate question. Neither is it an aggregate. So kindly leave it alone. Xp
Like any other such term, these terms are used differently in different places, and are sometimes interchangeable. Here's what the differences typically are:
The Application Architect is is what many of us just call the Architect. The person responsible for the highest levels of design and scope for a particular solution/project. You'd bother using Application in the title if there were other types of architects around, and you wanted it clear that this person worries mainly about a particular application.
The Enterprise Architect is worried
about all of a companies solutions.
How they rely on each other, how they
use each other, how efficient can
their common upkeep and improvement
be made. He thinks about how all the solutions together support the company's mission. Only a larger company could warrant this grandiose title. The Enterprise Architect is a big shot who meets with the CIO, CTO, and other such big shots.
The Systems Architect might be considered to have a wider scope than the Application Architect, and less than an Enterprise Architect. This title is sometimes the exact same thing as Application Architect - big shot on a particular project. Sometimes the System part of the title cannotes a wider scope: person who duties include software but also hardware and IT, or someone worried about multiple projects.
I've encountered quite a few architects with varying titles over the years, and I definitely have my own view on the role of each of them, however it does tend to vary from company to company, and even more so from country to country.
Enterprise Architect - responsible for strategic thinking, roadmaps, principles, and governance of the entire enterprise. Usually has a close relationship with the business, vendors, and senior IT management.
Solutions or Systems Architect - responsible for desiging a high level solution to a specific set of business requirements, within the framework laid down by the enterprise architecture team. This solution may span multiple applications.
Integration or SOA Architect - responsible for the integration and/or business service strategy and governance. Since this role usually spans the entire enterprise it is often performed by an EA, however an integration architect will usually work at a more detailed and technical level than an EA. In a SOA, an integration architect may also be a member (or even leader) of the centre of excellence (or integration competency centre)
Information Architect - responsible for defining data models, master data management / ownership solutions, and data quality processes to support transactional, reference data, and reporting systems throughout the enterprise. Often performed by an EA.
Application Architect - responsible for implementation of, and processes within, a specific application or suite of applications. The application in question may be bespoke of a customised of-the-shelf product. Should have deep knowledge of the product/application and will often be consulted by other architects as part of a larger solution
Those are the most common titles in my experience, but there are other architecture roles that you'll see from time-to-time:
Technical Architect (for me this is the same as an application architect but others may disagree
Business Architect (defines business strategy and processes)
Infrastructure Architect (servers, platform decisions, and often security)
Network Architect (obvious)
Well it sounds like your in school still but looking into the business world and expecting titles on the cards to be as structured as a degree system... its not.
Truth be told the business title is either a company specific job-title to support the internal pay-grade system or the org charts. Its hard to take from one company to another on anything more than very general terms. Its not really a benchmark like a BA or PHD.
As far as titles and job roles go, teams in companies generally break down into Infrastructure (Server setup and networking), and Applications (DB admins, developers) groups. There is a lot of variance by company but that seems to be pretty universal.
I think your best bet in planning is to decide what you like to do, and then study to do it very well. Along the way as an IT guy you have to pick up a little in all areas to be very effective in any area anyway..
Good luck!
What each means really is determined by the company you work for; what some call a Solution Architect others call a System Architect. They're all (assumed) senior positions with some implied oversight of system/software design but aside from that I've never seen one definition that will make everyone happy. "Enterprise" does imply some scope to the position, but it's arguably no different than "Systems" (again, depends on the company). Application Architect usually makes me think of someone who's been around as a senior developer for a while and HR needed a new title to reward performance. Sort of like the way some massive companies lob the "Vice President" title around to the point it doesn't really mean anything besides how many vacation days you get.
What the Hell..
Architect:
Application - designs applications
Systems - designs multiple applications and coordinates into a system
Enterprise - designs systems and coordinates with the other non system aspects of the business enterprise.
Let's not forget salary, bonus and how much time you spend on worrying about your title.
Enterprise Architect is biggest role of all. He has to have complete technological implementation knowledge.
Closed. This question is off-topic. It is not currently accepting answers.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Today I had a bad surprise learning about some implications of the GPL license, mainly that I couldn't use it as freely as I thought.
Now I know.
What else should I know, and more widely, what should every developer know about legal things like that?
You can separate employees, freelancers, open source projects contributors (etc.) or give a more broad answer.
Twelve Legal Considerations for Software Development
Software is copyrighted if it is made available to the general public. It is no longer necessary to put a copyright notice on the application or in the source code. The owner of the copyright is the author(s) or company paying the author(s).
The copyright of software can be assigned by the owner of the copyright, or it can be retained by the owner and the software can be licensed to the user or users by the owner.
Libraries used in development probably have restrictions in their use and distribution. GPL does not make a library public domain, nor does the fact that the library comes with a development platform. You should read and understand the license before you distribute your application. Some libraries require royalty payments, although this has become less common in recent years.
Software patent lawsuits are crap shoots. You should not, of course, knowingly violate a software patent. However, there is a small but real chance some company will sue you for violating their patent. This may happen even if you develop your software independently, you never heard of the patent, and the patent covers a technique that is intuitively obvious and almost completely unrelated to your software. There is not a lot you can do to avoid this, given the current USPTO policies, other than buy insurance. The good news is that patent trolls generally sue large companies with lots of money.
If you use an employee or freelancer to develop software, you should make it clear, in writing, who owns the copyright to the application, including the source code. Some freelancers and contract development companies consider the source code their own property, leaving the company dependent on the original developer(s). This is legal if it's in the development agreement.
If you have an employee who develops software "off the clock," you should make it clear who owns that software, and what kind of software the employee should be able to write and distribute outside of the company.
If you are an employee or freelancer developing software, you should make it clear who will own the copyright to your application, before you begin development. Also, you should know or clarify who owns software you write on your own time. Some companies have clauses in employment agreements claiming ownership to any software written by a developer during the period of employment, whether at home or at work. Many companies have non-compete clauses in employment agreements that restrict the software an employee can produce for distribution outside the company. Sometimes these restrictions are pretty broad.
A trademark is a name or symbol, not the software itself. If you distribute software, you should (a) make sure your application name and "mark" or design of the name is not "confusingly similar" with other applications, and (b) register your trademark. Date of first use is important in resolving conflicts, so you should document when the application is first used in commerce.
When you name an application, check for registered trademarks, but also check Google. An application with first use of the name may be able to take your name and trademark after your application is successful, even if they have not registered the trademark and you have.
When you use or sign a contract or agreement, make sure both parties understand it. In an employment agreement, mentioning any potentially sensitive areas up front can prevent a lot of problems later. In a development agreement, if both parties know who owns the source code, or who is responsible for upgrades, or who is responsible for maintenance, etc., going into the development project, then there is much less likelihood of a lawsuit after the application has been completed. In a distribution agreement, make sure the distributor understands the responsibilities and term of the agreement.
Every non-trivial application has bugs (or "design considerations" :-)). Any user agreement or distribution agreement should make it clear that you are not responsible for bug-free software, and you cannot be expected to fix all bugs. Make it clear that changes, fixes, and upgrades are made at the option (or best efforts) of the developer, and make it clear who pays for fixes and upgrades.
Even after you consult a lawyer about software development and distribution agreements, you should read agreements from other software companies and see what their lawyers came up with.
I am not a lawyer, and this is not legal advice.
When in doubt, contact a lawyer.
I'm no lawyer but over time I have gathered a few rules of thumb from legal people that you can use to save time:
GPL license is 'copy-left' or 'viral'. It means that any code that you write that depends on a GPL component must also be released under GPL. A good rule of thumb is that if you need a GPL component to compile your software, your software must be released under a GPL license.
You are not obliged to make your source available if you're not distributing your software. For example, if you run the software for internal purposes or on a web server you do not need to release the source. That is why Google doesn't need to release their software that use GPL libraries. It was a key contention point in GPL v3.
LGPL (Library or Lesser GPL) only requires you to GPL your own source code if you incorporate the LGPL-ed library in such a way that it becomes irreplaceable. Your own software do not need to be GPL if you only 'use' the library. Including header files and linking against a .dll/.so of the library is one of the ways you can 'use' LGPL-ed code without any obligations, except for the proper copyright notice.
BSD License (the Apache License is very similar) allows you to create commercial extensions of that use the open source component. That is why Apple chose FreeBSD over Linux as the kernel for OSX.
MPL is very commercial friendly because Netscape thought that they might make some money out of Mozilla at the time the license was written.
It often helps to contact the maintainer of the Open Source project. They are in the best position to advice you about the original intention of the license as well as their own views on open source. Sometimes maintainers are willing to release software under multiple licenses to help you out. Often they are not. Depends on the person who owns the copyright.
The KDE project has a handy matrix
I think Legal Guide to Web & Software Development by Stephen Fishman Attorney is what you're looking for.
Review
An amazing book! Answers nearly
every legal question you can imagine
and some you would have never thought
of. -- John Dvorak, PC Magazine
Covers every imaginable detail
important to such a rapidly growing
and intangible medium. -- Entrepreneur
This book passes my own personal test
for legal guides --with higher marks
than any other legal guide. -- Jeff
Duntemann, Editor, PC Techniques
Magazine
Product Description
Protect your rights, and your hard work!
The laws covering website and software
development are complex and confusing,
but if you don't untangle them, it
could cost you thousands of dollars in
attorneys' fees and lawsuits.
Fortunately, Legal Guide to Web &
Software Development decodes this
complex area of the law, thoroughly
and in reader-friendly English. It
also provides contracts, agreements
and legal forms on CD-ROM, with
step-by-step instructions for filling
them out, so you can protect your
software and website without paying a
lawyer's ransom.
Use Legal Guide to Web & Software
Development to learn:
what kind of legal protection you need
the strengths and limitations of each type of protection
how to avoid infringement
which provisions you need when drafting an agreement
how to obtain permission to use other people's materials
You'll find complete, step-by-step
instructions to draft:
employment agreements
contractor and consultant agreements
development agreements
license agreements
The 5th edition of Legal Guide to Web
& Software Development is completely
updated to provide the latest case law
and statutory revisions.
Some other suggestions :
Working for Yourself: Law & Taxes for Independent Contractors, Freelancers & Consultants (Same author).
Consultant & Independent Contractor Agreements (Same author).
Software Licensing Handbook by Jeffrey I. Gordon.
Practical Guide to Software Licensing for Licensees & Licensors by H. Ward Classen.
The Tech Contracts Pocket Guide: Software and Services Agreements for Salespeople, Contract Managers, Business Developers, and Lawyers by David Tollen.
If a freelancer or contractor: make sure you have good liability insurance and know what's covered under it.
For instance, mine doesn't cover liability for mistakes made in code that might expose credit card numbers. So I don't touch that stuff any more!
For employees : we should be able to give a first round of advice to your clients -- like can they/we use the component we want, in their application ?
For freelancers : we must be able to give strong advice to your clients ; and choose which components we can use for the applications we develop for them.
You course, your word is not as good as the advices a lawyer can get you ; but you can already help for a first round ; for instance, to say "we definitly can't use this because it would mean..."
In the end, the lawyer will know much about corner cases -- but if you can help a bit...
For OSS contributors : knowing some differences between free licences can matter if you care what people can do with your code (redistribute ? modify ? use it in commercial application ? use it in proprietary application ? )
One answer has asserted that the law is not like code. I disagree.
In the early days, IBM paid programmers by the instruction. (Someone I knew said he worked with a programmer who got rich this way. Apparently the guy didn't know how to use the machine's index register; he wrote a memory-zero routine that manually stored zero in each memory address.)
There was also a time (long ago) when lawyers were paid by the word. This helped to popularise practices such as addressing people as "the most highly esteemed such-and-such" and other verbosities.
I just read an answer on SO that said VB.NET 2008 still allows line numbers. You can still run pure DOS on a modern PC. And there is much truth to the joke that all COBOL programs are decended from a common ancestor by incremental changes. Backwards-compatibility, and "historical reasons", are rife in our field.
This is comparable to the realm of law. There are laws which make small (or big) changes to other laws. You've got a kind of dependency-hell. There are some ridiculous historical laws (in Hobart, Tasmania, it's illegal for a man to wear a woman's dress after sunset - because once upon a time, convicts would dress up as women and mug people) that nobody would dream of enforcing, just as there are some historical features in software that nobody uses anymore.
Laws often have unintended consequeuences (bugs!), get used in creative ways (hacks!), contain loopholes (security vulnerabilities!), some of which are intentional (backdoors!), get modified (patches!) or overturned (uninstallation!).
Yes, laws (unlike code) are subject to interpretation. But I think this is rather like code maintenance. It helps to adjust laws to new social norms.
To answer the question directly: every developer should know that law is rather like a ridiculously enormous software project that has been in development for hundreds of years. (Actually, each country has its own project, and they solve problems in different ways.) In theory, after reading a licence you will know what you can and can't do with your code. But if a competent programmer can't spot all the bugs in his code just by reading it, then what chance does a non-lawyer have of analysing the corner cases and grey areas of a legal document?
Like with software source code, you can usually get the gist of a legal document by reading it, but if you need to know something specific, ask a professional.
NOLO (I don't work for them) publishes a good set of legal how to books for the layman.
http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html
I would answer this in the same way that I would answer "what should every lawyer know about programming?" That is to say, know that there's no way you can possibly know the in-depth field well enough to do more than the simplest of things. Get an expert.
You should know the basic rights and obligations of the license you are going to use. It's not that hard, and even if there are plenty of them, you need to read carefully only those you are going to use or touch. Just read them, in most cases they are quite clear.
Anything else you could need, well, that depends. Patenting ? Trademarks ? If you need these things, chances are that you are in a company and have a legal department to do this for you.
I would always assume that the developers of a project want any software using their work to be released under the exact same licence. Read their FAQs and legal pages for more information and don't hesitate to contact the developers/maintainers if you are still unsure.
If you want help understanding the details of a licence agreement, talk to a lawyer.
Don't work in a country that has more lawyers than developers.
An extremely large percentage of all (U.S.) software patents are bogus, but you can't pay or wait for them to be invalidated.
If you want to use/develop open source software, use an existing license and don't modify it. Don't go near the borders of what the license is supposed to mean.
The name of a good IP lawyer.
6.If you have an employee who develops software "off the clock," you should make it clear who owns > that software, and what kind of software the employee should be able to write and distribute
outside of the company.
freedom of speech right as stated in most constitutions (esp. if devs make free s/w off-the-clock) can make such terms fail miserably in courts
The law is not like code. It is not a well cast set of steps and rules that can be unambiguously understood.