Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I easily forget to regularly make local git commits, and so i've developed the bad habit of having a few very large commits. I'd really like to make lots of small commits. Largely so the messages are more explicit.
I know myself well enough to know that this isn't just going to magically happen by me remembering. I'm more likely to be successful if I implement a system that pushes me to do this.
Here's what I'd like, either an Xcode plugin, an Applescript or an xCode behavior trigger that systematically initiates the commit command (cmd-option c) within Xcode (or i suppose i'd explore alternatives, but it'd be nice to stay within xCode). It can do this either based on the number of files changed, or amount of time elapsed, or possibly on a "build and run" or any other reasonable behavior. At any rate, i'd like for it to be somewhat configurable and where it could be enabled and disabled easily.
So is there something this already out there? If not, do you have any guidance on how I might get started with a potential solution.
Interesting Question
You might want to extrapolate from the following code found on this website. One might generate a unique but standardized text message combined with a folder name/date combination as the automated commit message or take the script and make it runnable to accept a parameter as input with the message being the parameter. I suppose though that might be as much work as typing git commit in the terminal. Instead you may want to use this script in combination with Folder Actions to monitor activity on a folder with the script acting as a service.
(* Copyright (C) 2012 Collin Donnell
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. *)
tell application "Finder"
set current_path to (POSIX path of (target of front window as alias))
set commit_message to text returned of (display dialog "Commit message: " buttons {"Cancel", "Commit"} with title "Commit All" cancel button "Cancel" default button "Commit" default answer "")
try
do shell script ("cd \"" & current_path & "\"; git commit -am" & quoted form of commit_message)
on error the_error
display dialog the_error buttons {"OK"} with icon caution with title "Error"
end try
end tell
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
Does anyone know the license under which rubygems (http://production.cf.rubygems.org/rubygems/rubygems-2.0.4.tgz) itself can be redistributed? The rubygem.org seems to have no mention of this...
Thanks Rags
The RubyGems license:
RubyGems is copyrighted free software by Chad Fowler, Rich Kilmer, Jim
Weirich and others. You can redistribute it and/or modify it under
either the terms of the MIT license (see the file MIT.txt), or the
conditions below:
1. You may make and give away verbatim copies of the source form of the
software without restriction, provided that you duplicate all of the
original copyright notices and associated disclaimers.
2. You may modify your copy of the software in any way, provided that
you do at least ONE of the following:
a. place your modifications in the Public Domain or otherwise
make them Freely Available, such as by posting said
modifications to Usenet or an equivalent medium, or by allowing
the author to include your modifications in the software.
b. use the modified software only within your corporation or
organization.
c. give non-standard executables non-standard names, with
instructions on where to get the original software distribution.
d. make other distribution arrangements with the author.
3. You may distribute the software in object code or executable
form, provided that you do at least ONE of the following:
a. distribute the executables and library files of the software,
together with instructions (in the manual page or equivalent)
on where to get the original distribution.
b. accompany the distribution with the machine-readable source of
the software.
c. give non-standard executables non-standard names, with
instructions on where to get the original software distribution.
d. make other distribution arrangements with the author.
4. You may modify and include the part of the software into any other
software (possibly commercial).
5. The scripts and library files supplied as input to or produced as
output from the software do not automatically fall under the
copyright of the software, but belong to whomever generated them,
and may be sold commercially, and may be aggregated with this
software.
6. THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.
(It's in the LICENSE.txt file in the tarball you linked.)
It is distributed under the MIT license according to the git repo: https://github.com/rubygems/rubygems/blob/master/LICENSE.txt
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I work for an IT services company that develops products as enablers for further services consulting. We have technical consultants/developers that need to be able to develop remotely and when back in the office "on the bench".
What methodology/process/tools support development by consultants when they are remote, or "on the bench", in particular how to support the management of the deliverables.
I have looked at DVCS systems, along with KanBan board tools, but I'd like to get opinions in the best way to handle this style of product development when it's not a traditional back room development situation.
Here's my TFS pitch.
Your developers/consultants need to be able to work in house, remotely or offline. That means local workspaces. TFS 2012 has that.
With the high rate of turnover, you need managers to be able to easily and quickly assign specific tasks to developers. With TFS you can create work items, break them into subtasks and easily assign them to any team member. When the developer begins working, you'll be able to see it and any check ins can be quickly associated (semi-automatically) with the subtask. So you'll know who did what task, and be able to see the exact code they implemented to accomplish it.
If you have managers maintaining the product backlog, all a developer needs to do is select one of the tasks assigned to him, get the latest from the source and start developing. Minimal overhead for him/her.
With Web Access you can see/edit your entire product backlog, get burndown charts (and other reports), see who completed what and when, assign tasks to team members, change team members, etc. All without VS installed, so no need to have a license for a manager if they don't develop.
Finally, fully integrated automated builds will allow you to ensure that consultants don't break your source. Gated check ins are great for this kind of team. The changeset is stored, and a build is ran. If the changeset would break the build, the check in is denied. You can also automate builds on the other side, post check in.
Any file created outside of VS can be easily added to source control. Once the file is added, TFS monitors the file for changes and you can easily add the changes to a changeset. Once in source control, its fully in source control and available to everyone.
You never really mentioned any database requirements, but the new SSDT is awesome for declarative SQL development. So far, I've not had to write a single ALTER script, which makes me very happy.
There is also fully integrated support for code reviews, build verification tests, automated deployments, architecture tools (with rules that can be enforced) and more. The rabbit hole goes pretty deep, but if you don't need it, none of it is forced on you.
So, the methodology I would suggest is a KanBan style set up, with managers pushing tasks rather than developers pulling them. This way you can reduce the impact of your high turnover rates without overly micromanaging your consultants. You'll be able to easily give them a task, let them accomplish it, and have complete visibility of the work they perform. I'm not sure how you gather your requirements, and how much input in the dev process your customers have, so its hard to go into more detail. TFS supports storyboards associated with work items, so you can give detailed specs to your developers. Also the Feedback Manager can facilitate in getting feedback on working software from product owners.
You could go Scrum with defined sprints, but I think a lot of the overhead of sprint reviews and sprint planning may be a waste for you, if you consultant turnover rate is high, and/or you don't need/want a lot of input from your consultants on user story breakdowns/requirements gathering.
There are several leaders in the ALM space, including VersionOne, Rally, ThoughtWorks Studios Mingle + Go + Twist, Jira Greenhopper, and others. These are all fundamentally iterative in nature, supporting Scrum+XP. There is a new crop of tools coming up that support Kanban, if that's your preference.
The key, though, is to decide what approach you plan to take. Iterative or flow?
Beyond that, if you're using a continuous integration server - whether open source like Jenkins or commercial like Go - then that combined with an SCM system (git, for instance) gives you visibility into what's been produced and the ability to distribute that work.
Back to your specific challenge, it seems to me that iterative wouldn't suit you, since you have people coming and going as they enter and leave the bench. Mingle supports this quite nicely, as do a few of the others. In fact, I'd suggest that the leading methodologies don't really lend themselves to your situation, as you will have neither iterations nor flow, most likely.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
What do you have to do to a piece of software so that if a user, Vista/Windows 7, double clicks the .exe file the message: "do you want to allow the following program from an unknown source to make changes to this computer?" is not displayed to the user?
I mean, do you have to get your software vetted by MS, I'm just wondering what the process is?!
And I don't mean disable UAC on the machine itself! :)
Thanks.
No, this is not a duplicate of the UAC/Administrator rights question per se. Yes, it's UAC. But it has less to do with the USER (who may or may not be a member of "Administrators"), than with where the program was INSTALLED.
This link explains:
http://answers.microsoft.com/en-us/windows/forum/windows_7-security/uac-message-do-you-want-to-allow-the-following/bea30ad8-9ef8-4897-aab4-841a65f7af71
This occurs when unknown programs (unsigned) try write data to protected system folders or registry settings, and UAC is seeking your permission. This type of activity could be dangerous anytime, so it prompts every time.
One way to fix these issues is to uninstall the program, then install it somewhere other than the Program Files folder or top of the C: drive... somewhere like your user folder would do perfect. Then the program can run in the default security context and still have write access to itself (its own folders), which is the usual culprit.
The easiest way to resolve (outside of not putting stuff in c:\Program files on Vista or higher and/or signing your .exe) is to simply UNCHECK the box "always ask before opening this file.
Another good link:
http://blogs.msdn.com/b/askie/archive/2009/06/19/how-to-bypass-the-security-warning-unknown-publisher-with-the-checkbox-always-ask-before-opening-this-file.aspx
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We plan to sell a Windows portable application. By 'portable' I mean that it can be run from any Windows computer without installing it. For example from an USB stick etc. However the application while (theoretically) it can work anywhere, is targeted to LAN environments.
What solutions do you see that while keeping this advantage (in a more or a lesser degree) to still make money from it?
PS: The application is/will be written in Delphi.
If you are offering your product for sale and not for free, then you will most likely make money from it. If what you are asking is how to maximize the income and prevent piracy, then that is a more specific question.
The key to making money with software is to make the purchase route less painful then the piracy route. Usually the biggest hurdle to purchasing software is the price tag (but not always, some people just will never buy software and always pirate, but you can't do anything about that). And the biggest hurdle to piracy is some sort of DRM scheme, which is actually the second largest hurdle to purchasing software. Often times DRM only annoys the legitimate purchases, while the pirated version has all the DRM removed with less effort then you spend to put it in. Thanks to the wonder of electronic duplication, once the DRM is removed, then everyone can have a DRM free copy.
So you want a solution that only annoys illegitimate usage, but not legitimate purchases. This is much harder to do then expected.
Depending on the price tag for your software you might consider deploying it on a keyed USB drive (i.e. Dongle or USB stick with some special key). Then it is portable, but only on the hardware you provide. The user never has to worry about a secondary authentication scheme, and the DRM only becomes an issue when the hardware (which is harder to duplicate) is changed.
You say that it is only for a LAN environment, which doesn't necessarily mean that the computers will have internet access (and if they do, they probably have a proxy requirement) which means "phoning home" will be problematic. If you want the product to only be used on a specific LAN then you might require a license server to be installed on the LAN. Then the software could always check with the license server to make sure it is authorized. That won't work if you want it to run on multiple LAN's though.
Conversely if your price is low enough then most companies and people would rather buy the correct licenses and not risk the piracy. In actuality, depending on your clientele, most people will prefer legitimate licenses when they can, and DRM can actually discourage them from buying licenses.
Some alternatives:
Use a dongle, where the user of the software must plug in the dongle before your application can work.
At startup read a configuration file and if this is invalid or missing, halt the application or reduce its functionality. The configuration file should contain information about the user or company that licensed your software, and also a checksum to prevent users from changing the file. With such a file, serious companies are less likely to distribute this configuration files to others. Of course, you should then create one such configuration file per user that licenses your software.
Optionally, include specific computer information (type, memory, bios date, system guid, ...) that prevents the application from being run on other computers.
Make sure you make money from the service you can deliver, not only from the software you are selling. This service can include: providing upgrades, taking suggestions for improvements, assisting with problems, helping with domain-specific knowledge, ...
You can use some sort of license file and a "phone home" option that makes sure the same license is not used at more than one place concurrently.
If you have a large ordfer, you could try to get a memory stick with a special serial number and/or value in it that you can read out in the software (eg the exe must reside on a special memory stick)
Please note that a lot of users get quite annoyed by these things (we've used the first option)
Also please note that if commercially interesting, your app will be hacked. Make sure the effort someone has to take outweighs the profit the could make
One approach that also helps some is by custom branding. Each copy you sell would have compiled into it the name of the company it was sold too, which can be displayed as part of the splash screen as well as the about screen (along with a button to view the license terms). Most often this branding is done by using an external file which contains the information encrypted that when placed in the same directory as the executable is used to unlock the application as well as possibly provide additional functionality.
Unfortunately with todays software firewalls, most of the simple solutions to disallow running multiple copies on a network are not practical while still maintaining true portability, or requiring internet access to a server that you fully control.
Yes, piracy is a problem, but if you continue to offer great support and there is an additional "visible" benefit to purchasing, you can help offset this in your favor.
If you need trial protection, you can count uses/days if you have any sort of database where the user will have invested time and data, and won't want to lose it. Just encrypt the counter and place in the database somwhere. The user can then only reset the trial by wiping out the database. Depending on the type of app, this may be effective, or not.
Another approach is to not have a portable trial at all, but offer it as an incentive for purchase. i.e. conduct the trial on the desktop, and when they purchase a license, they get a license key that allows it to run on portable devices.
I recommend the PortableApps.Com framework for launching your app. It's free. You need to make your "launcher" open-source, but not your app itself. You can still run on a bare drive, if you follow their pattern.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have received a request of buying the source code of a website I have developed and I wondered if anybody have been in the same situation and if there is anything I should specially be aware of. Anybody got some advise on how I should handle this situation?
First - a caveat - I'm not a lawer. Not at all. But I care alot about intellectual property and not getting sued, so I try to learn about it a bit.
In no particular order:
Double check your employment rules - when you took the job currently paying you money, what is your arrangment? Did you have to sign any statements giving your company control over all the code you produced? Even if it was a personal, unpaid project - corporate ownership can get you if you signed a strict intellectual property agreement.
Used open source? - there are a few main open source licenses, read through and check them to see the terms for sale of a product with dependancies on open source.
What deliverables does buyer expect? - Built code? source code? Also - what can you do to protect your code (obfuscation).
Do they expect support? - be careful, in my experience with corporate customers, a helpful, free of charge "sure, just call me if you have a quick question" can quickly become time consuming. If you are willing to throw in a free couple hours, be very clear that you will give up to X hours of support for free. And be clear about what your billing rate is after. If you really don't want to support it, make the cost of your time very high.
What sort of support do they want? - answers & configuration help? Bug fixes?
What sort of installation instructions are expected?
What do they own when they buy this? - a single installation for a single server? a site-wide license to install it wherever they wish? or --- worst case -- do they own this lock, stock and barrel such that you may no longer develop it and continue to use it yourself?
Get these answers cleared up, in writing, with signatures.
It's a good idea to have someone external read it to check for ambiguity.
It's an even better idea to draw up the agreement and have a lawyer read it - your lawyer, not the buyer's lawyer.
Avoid any nod/wink/handshake deals. Personal trust is great, but people change if the situation becomes stressful. Or people come and go within companies - the buyer today may be a different person tomorrow.
The first thing you need to consider is:
What license are you providing the code under?
If you don't stipulate a license, they're pretty much free to do with it what they want. Is that what you want? It's hard to answer the question without knowing the specifics of the situation: why are you selling the source code?
If this is a customer and so it's they can do their own custom modifications that you were otherwise being paid to do, the price should reflect that "lost work". Also, you will want to limit their ability to redistribute or resell that source code.
If someone just likes your site and wants the code, be very wary because there's every chance they'll just take it and set up their own. This may or may not be an issue for you. But again consider the issues of resale, redistribution, usage rights and ownership.
Depending on what the code is for, you may also want to consider what it is used for, what it can be used for and how that will affect you professionally or otherwise. It's possibly you may want to restrict the code from being used for certain things (eg adult or poker sites) or you want to require attribution.
Also for all of these things, you need to consider what terms transfer in the event of redistribution (ie how "viral" your license is).
There are lots of open source licenses out there (GPL, Apache, MIT, BSD, MPL, LGPL, etc). I'd suggest you take one as a basis and modify it to suit your tastes. You're far less likely to get in trouble that way than you are with coming up with your own terms.