Related
A friend of mine is in the real estate business and after being showed the art of writing copy for real estate ads, I realized that it is very formulaic. Especially when advertising online as there are predefined fields you fill in.
Naturally, I thought about creating a generator that pretty much automates writing the ads. i don't expect it to generate outstanding or even very good copy, just that it can put together words and sentences like a human would.
I have a skeleton/template that defines an ad and I've also put together a set of phrases and words that can be randomly selected, but I am interested in more general aspects of coding such a generator? Any suggestions, tips or literature that I can read to better understand this little project better?
using metadata about the listing would be one way.
Say for a given house, you have these attributes:
(type: bungalo, sq feet: <= 1400) You could use the phrase "cozy cottage".
bedrooms: obvious, same thing with bathrooms. Assume using the word Large, medium, etc.
garage spots: if > 2 then "Can park many vehicles", etc.
You could go even further with this given the lat/lon for the address, there are web services that you can find the amount of parks nearby, crime in the neighborhood, etc.
Rick
I'd say there are three basic approaches you could take to a problem like this, depending on how flexible you want the system to be and on how much work you want to put into it. The simplest is to treat it as a report generation problem, along the lines of Rick's suggestion. That's probably the way I'd go to produce a first draft of a listing. The results would be pure boilerplate, but each listing could be quickly punched up by the copywriter.
If you wanted to get fancy, though, you could come at it as a natural language generation problem. You'd start with some kind of a knowledge representation describing the meaning of the listing and set of rules (finite state transducers, say) for mapping meanings to linguistic forms. There's a sizable academic literature on that kind of stuff, though it's kind of out of fashion these days. Places to start might be Blackburn & Bos's book or the NLTK suite (especially some of the projects in the contrib package).
The third way of doing it would be to treat it as a translation problem, essentially "translating" database entries into ad copy. You'd start with a large collection of listings and the corresponding human-written ads and construct a statistical model of the relationship between the two. Moses/Giza++ is a general purpose tool for building and applying such models.
We have a number of AS/Flex components that we've built over time and improved upon. They've been turned into components so they can be reused in different projects and save us time. So you can think of them as part of an in-house framework of sorts.
We're now realizing that it doesn't make sense to release the source code for these components to the various clients as part of the project, because technically this code isn't really owned by the clients.
So my question
When a client comes to you, how do you explain to them that you can't give them the full source code for those components. The client doesn't understand the difference, he just expects you to give them all the code for the site that he paid you to do. He doesn't understand that this code has taken you a lot longer to write than what he's paying for his site. But since he doesn't understand, he would get turned off and thinks you're ripping him off or something.
How do you handle this situation? What do you tell clients upfront? Do you advertise it on your site from the very beginning? How do you handle their objections so they still hire you?
As a side question, how often do you give AS and Flex source code to your clients? In the case when the code doesn't have any in-house components that you reuse in several projects, and in the case when it does have in-house components.
I'd also like to hear from people who've worked at creative agencies since they're most likely have run into that issue already.
I'd explain to my client how the world works. I'd use examples, analogies and metaphors.
This isn't a software-development issue, this applies to all products. Some things are sold as black-box, and some things are sold as a clear-box containing black-boxes inside it.
Lets say you wish to buy a house. You pay the engineer and the architect for their work, and you gain the documents they produce. These documents contain information that relies on other pieces of information, which you do not gain. For example, the engineer may use huge steel bars in his plans. The engineer's specifications determine the qualities that each steel bar must have, but they do not specify how the steel bars are created. Buying house plans doesn't buy you the plans for creating the house's building blocks.
With softwre it is pretty much the same: you don't get the source code for the .NET framework when you buy a .NET application "with sourcecode included". What you do get is the .NET documentation, specifying how to work with the framework (and not specifying how the framework does what it does).
The amount of examples is actually endless, because - as stated above - this is the way the world works.
Build your own analogies to fit your scenario. Explain to your customer where the infrastructure ends and his owned solution begins.
quoo is right about the need to specify these in the contract. The contract is the legal backbone of the deal. But i'd like to emphasise the fact that pointing at the contract should be a last resort. If you can give your client a reasonable explanation such that lets the client understand why things are the way they are, you won't need to wave the contract (which speficies only the way things are, without the motivation, explanation, etc.).
I'm not a business person, but generally these things are specified in the contract. If your contract stipulates that you provide the client with the source code at the end of the project, then at the very least, you should be providing them with swcs of your components so they can recompile the code if necessary. If you don't want to share your code with the client, then that too is something that you'll need to specify up front.
Just explain that you can not provide the source for external libraries that you used on his project to make the bid cheaper for him. He would not expect the source from a 3rd party vendor that you used in his project, just try to explain this is the exact same situation.
Intellectual property issues should be covered upfront as part of the contract. I'm not a lawyer but common practise is to specify:
Which components are provided by third parties and refer to their licensing terms
Which code will be produced as part of the contract.
Whether you license or sell various intellectual property rights.
Licensing terms.
Intellectual Property laws` are complex and diverse, they differ from country to country. Depending where you're and where your customer is the licensing terms might need to change. As an example, reverse engineering viewed differently in different jurisdictions.
Apart from third-party components and software bits you don't want to sell, nor give an exclusive license for you'd probably want to be able to exhibit and distribute the works as part of your company portfolio. This latter activity would also need to be covered within the contract.
Having a well written contract prepared up front will save a lot of misunderstanding and unnecessary negotiations. You'd probably need just one template you could use for all your customers. So my advice really is "talk to a lawyer".
Your contract should make clear that components developed by you are licensed to the client for use as part of the project and only the project(s) you did for them. Of course, you'll need to determine the exact language for yourself and the situation, but if you're repeatedly using these components in your projects, you really ought to have some sort of boilerplate for just this situation.
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.
A little background: I have the opportunity to present the idea of a public API to the management of a large car sharing company in my country. Currently, the only options to book a car are a very slow web interface and a hard to reach call center. So I'm excited of the possiblity of writing my own search interface, integrating this functionality into other products and applications etc.
The problem: Due to the special nature of this company, I'll first have to get my proposal trough a comission, which is entirely made up of non-technical and rather conservative people. How do I explain the concept of an API to such an audience?
Don't explain technical details like an API. State the business problem and your solution to the business problem - and how it would impact their bottom line.
For years, sales people have based pitches on two things: Features and Benefit. Each feature should have an associated benefit (to somebody, and preferably everybody). In this case, you're apparently planning to break what's basically a monolithic application into (at least) two pieces: a front end and a back end. The obvious benefits are that 1) each works independently, so development of each is easier. 2) different people can develop the different pieces, 3) it's easier to increase capacity by simply buying more hardware.
Though you haven't said it explicitly, I'd guess one intent is to publicly document the API. This allows outside developers to take over (at least some) development of the front-end code (often for free, no less) while you retain control over the parts that are crucial to your business process. You can more easily [allow others to] add new front-end code to address new market segments while retaining security/certainty that the underlying business process won't be disturbed in the process.
HardCode's answer is correct in that you should really should concentrate on the business issues and benefits.
However, if you really feel you need to explain something you could use the medical receptionist analogue.
A medical practice has it's own patient database and appointment scheduling system used by it's admin and medical staff. This might be pretty complex internally.
However when you want to book an appointment as a patient you talk to the receptionist with a simple set of commands - 'I want an appointment', 'I want to see doctor X', 'I feel sick' and they interface to their systems based on your medical history, the symptoms presented and resource availability to give you an appointment - '4:30pm tomorrow' - in simple language.
So, roughly speaking using the receptionist is analogous to an exterior program using an API. It allows you to interact with a complex system to get the information you need without having to deal with the internal complexities.
They'll be able to understand the benefit of having a mobile phone app that can interact with the booking system, and an API is a necessary component of that. The second benefit of the API being public is that you won't necessarily have to write that app, someone else will be able to (whether or not they actually do is another question, of course).
You should explain which use cases will be improved by your project proposal. An what benefits they can expect, like customer satisfaction.