|
John R. Shaw wrote: Education takes time and the best education comes from experience and lots of research
I usually get stuck on the research.
|
|
|
|
|
|
I agree, a break in the action is likely to be exactly what you need.
I would also consider implementing a near-real world application for this stuff. So far, it looks like a lot of theoretical stuff to me. Kind of a solution in search of a problem. Try applying it to something that might be actually used. I missed that part if you have done so already. I find that one's initial implementation of lower level things often need adjustment when they are applied in an implementation so try to really work with it and see what shakes out. This could be something like a little scripting language or an assembler for some CPU or who knows what else? For something a little different, you could try your hand at even lower level code generation - assembler and/or machine. I wrote a machine code generator for my own script language and that was a ton of fun. Debugging it was quite an experience and then adapting all of that for my own custom debugger was off the charts fun.
That's all more code stuff so I think it would be best to first put down the mouse and take two steps back. Then turn around, walk/run away from the computer, and do something else.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
In terms of real world stuff, I parsed a C# subset with Parsley, and I use that subset in my apps to do work with it.
I haven't switched my hand rolled parser out for my generated parser yet, to be honest i'm a little afraid because it's so foundational to the rest of my build tools, but maybe that's a next step.
After a possible break.
hack everything.
|
|
|
|
|
. . . and I once made an English-to-Pig-Latin converter.* That's the real-world stuff you really need to embrace.
* also an alternate way to demonstrate recursion.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
For the longer run it might help people like me to give useful feedback if your longer term objectives are slightly clearer than right now. If you want to contribute to the field of parsing and parser generators (or even further, the field of compilers), then "not being sure it would work exactly" should just be the trigger to tackle the problem. That is basically what research, whether professional or hobby, is all about. If in the end it does not work, then you probably
understand why it does not work, which could help you and - if you document your work - others to solve - or at least address - that and related problems.
If - on the other hand - you just want to write code, then it might be helpful to look around and notice that there are other fields where you can hobby a little.
While writing compiler like stuff is fun - I did it long time ago for a long time with self-developed tools as parser- and codegenerator- and other tool-generators- one of the things is
that - unless you write compiler stuff for which there is a users group - it is nicer to write programs/systems - as hobby - for which there is a user base so that you can get feed back.
For the short term, I would agree with some others by suggesting to empty your head (do not take this literal), and do for some weeks something completely different, painting the house, fixing things that wait far too long to be repaired, go to china for a visit, go ...
|
|
|
|
|
I usually do whatever is appealing at the time, the only caveat being that I try to get something to a decent level of quality before moving on. My code has so many things that should be added that it offers adequate variety. Now that I've gotten active on this site, writing articles is another option. And then there's serious stuff outside of software, which for me are tennis and investing.
|
|
|
|
|
In the world of software defined everying, what about software defined parsing systems, or more generally software defined software  I know it sounds recursive but could be extremely powerful if handled right ...
In such a system, software systems are classified into layers. Upper layer software generates lower ones. The upper layer software (or meta software) should not depend on lower layer ones (like C#, C++, etc) except inside of the generators (i.e. one should not hand write lower layer software using other tools besides the generator), etc. To realize it, one need to develop tools to handle the complexity because the meta languages are most likely not like conventional langauges since they targets particular domain of application and related knowledge ...
For example, if one needs to generate relational database (RDB) related systems that target particular database schema and user specification, the knowlodge is the ones related to RDB in general and the said schema and user specification in particular. It is the developer's job to handle it in general. Unlike the lower level languages, the way how knowledge is inputed, expressed and preserved is one of the challenges one faces here. One could find him/her self triversing knowledge trees more often than the syntax trees here and had to deal with context, etc ...
We use our own x-script system to do it and it was successful. The said generator can auto generate the whole system without human intervention given a particular schema and user specification. It could generates fully consistent codes consisting of 10th of millions of lines that are virtually impossible to produce by human coders ... We are developing a software defined network system (SDN) right now using similar approch and it looks quite promising.
If you could produce a general software defined (computer) language system, that would be greate ...
|
|
|
|
|
Shuqian Ying wrote: In such a system, software systems are classified into layers. Upper layer software generates lower ones. The upper layer software (or meta software) should not depend on lower layer ones (like C#, C++, etc) except inside of the generators (i.e. one should not hand write lower layer software using other tools besides the generator), etc. To realize it, one need to develop tools to handle the complexity because the meta languages are most likely not like conventional langauges since they targets particular domain of application and related knowledge ...
This is already the architecture of my parser generators.
The upper layer is the grammar file (*.xbnf) - they generate lexer specs and parsers. The lexer specs are then generated by the lower layer (lexer tools)
My system allows for human intervention by allowing users to inject code into the generation process at key points, among other techniques such as modifying firsts and follows sets in the XBNF grammar input. All of this, including the code, is not actually code, but a spec.
The "code" is not code so much as it is a specification for generating code that looks an awful lot like C#. It can render the "real" code from it to C#, VB or whatever.
So there is no code in the grammars. Just specs. That the grammar spec has it's own embedded language doesn't change that even if that embedded language looks like C#.
hack everything.
|
|
|
|
|
Hi all,
- Customer asks you to make a program.
- To do that program you may need functions, code snippets... that you already created time ago.
- The customer wants you to sign down a confidentiality contract in which it states that the source code is customer's property.
- The problem with this is that you must sign down the confidentiality contract before starting working: you make the program design afterwards so you don't know what you will reuse at the end.
- Working in the industrial sector programming, libraries usually are not encrypted/linked therefore it's not possible to specify that all the code in certain library or file is left out of the contract, and in some systems you can't separate the code in files as you'd like...
- I can't give the source code at the end as some of my customers ask me to store the repositories in their servers so the code is directly there since the beginning.
I need to get legal advice but the lawyers I've contacted doesn't understand a thing about my questions...
Have you solved this kind of situation?
And if you have... How?
Thank you all! ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
By making the original agreement specific to "software written for this project" and excluding "pre-existing library modules" which may be provided in binary form but which aren't supplied in source code.
Most customers will understand that library software isn't being produced for them, and that you don't actually charge for the use of it - unless they would like you to reinvent it all in which case the extra time will have to be added to the contract price?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yes, that would be easy if the code is linked into a library...
But when you program robots or PLC's usually you can't do this as the code must be copied into the project as is...
|
|
|
|
|
I work at a robotics integrator and we've had similar situations in our engineering team. In the end, it usually came down to talking to the client about it.
These kinds of things are usually designed to protect the client from someone coming back later and demanding money. The code you'll be writing for this project will be owned by them and therefore never require a license agreement.
Are the function and code-snippets truly unique and novel or are they common implementation patterns that you apply to many projects? Just remember that if you write a for-loop for someone else doesn't mean you can't ever use a for-loop ever again.
So talk to the client. Let them know you have these functions and code snippets that you've used prior and plan to use in the future. That will help clear up the root issue they're trying to protect against.
...never send to know for whom the code faults; if faults for thee.
|
|
|
|
|
Pixelfish wrote: So talk to the client. Let them know you have these functions and code snippets that you've used prior and plan to use in the future. That will help clear up the root issue they're trying to protect against.
Although I don't disagree with what you have said, I just want to make a point that you should be careful what you talk to a client about. If this client is paranoid (maybe they have been burnt before) then this could get their tails up and cause more problems than it's worth.
This is even more so if the client is 'uneducated' in the world of programming - it might be nigh impossible to convince them that code by nature will always be 'similar', and they could easily just assume you are trying to scam them. Maybe even enough for them to decide to cut their loses and find someone else.
modified 9-Jan-20 9:54am.
|
|
|
|
|
"This code helps me develop faster, and therefore more cost effectively"
"I can do it without it, but the project will cost more and require more testing"
hack everything.
|
|
|
|
|
This is easily understood by the customer...
but will it be understood by a judge if a contract says the opposite?
and which would be the legal way to write that down in a contract?
|
|
|
|
|
If the contract is already in play, I don't know what say. This obv would only work if it was ironed out before anything was signed.
Sorry, I don't know what to tell you. 
hack everything.
|
|
|
|
|
Still not signed down...
But I need to find the right way to write this stuff...
Searching for software specialized lawyers in my area and I'm not lucky at all... 
|
|
|
|
|
I'm sorry to hear that. Best of luck to you.
Maybe you can find one that could consult long distance. My hubby works with some immigration lawyers in seattle that way sometimes (he's one of the few people in the world that is a non-native mixtec speaker)
Since it's mostly paperwork, it seems realistic, and it might widen your net when you search if you look nationally.
hack everything.
|
|
|
|
|
Or in Joan's case internationally.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I wouldn't take the term "library" too literally. You have an existing range of code "snippets" that you have either developed yourself or taken from the public domain, that's your library. Some of the "library" may even just be in your head, like how to open a file. But software development is about how you put those pieces together to achieve a specific result. If you try and get into much more detail than that, you can argue that the word "public" has been take from prior copyrighted works; ultimately, someone could copyright the values 1 and 0 and we'd all be stuffed.
I come across this issue quite frequently. At one stage I'd developed a market-specific application for a client, and staff members from that company left and started up (several different) competing companies and all came to me asking to write them the same application. Once non-competition clauses in my original contract expired I was able to provide very similar applications quite quickly because they were composed of basic generic building blocks that I use in virtually all my apps (a framework, effectively) - things like error logging, data access, configuration options; but also stuff like postcode validation/formatting, google address validation etc. I already had the domain "knowledge" so bolting these together was relatively simple. At times I couldn't quite remember how to do certain stuff so I might refer back to other code I'd written, but wouldn't say I "copied" it as such. At one stage I also translated the code from one .Net language to another, which was a trivial process but resulted in different source code.
If concerned about legal redress, you might want to refer to the process you're undertaking as "building" an application, rather than "developing" it. The size of your building blocks varies, and some might be used elsewhere; but you're putting them together in a unique, bespoke way for this client to achieve their specific goals. (See Playing all the right notes[^])
modified 10-Jan-20 5:25am.
|
|
|
|
|
You'd probably need to clarify what they mean by "property". Giving someone the source files and agreements that the code was written uniquely for them, or that you won't use the same code elsewhere are different things.
|
|
|
|
|
F-ES Sitecore wrote: you won't use the same code elsewhere
Is what they mean...
|
|
|
|
|
If that's what they want then it doesn't seem like a tenable contract. If you operate within certain industries you have to respect and understand the basics of how things work, and the fact that you might include libraries etc that don't belong to you is surely the norm in almost all software development.
|
|
|
|
|
A problem, If you want the job, ( I'm still "oozing" from one I took a while ago. ) try to explain the problem to them. - For me, something related would start with the prints for a job ( that started with prints for a job ) and code for a job ...
You have "inherited" knowledge from past jobs, that's why you have value to them.
It is possible to build something for them while NOT copying any or your old files. But not possible to not use your old experience.
I can see trying to declare "this section is yours alone, I create it for this job, I don't take it away" but even that is tricky, you may hold the files separate, but they are still in your head.
If they can't understand the problem, and help with a solution, maybe you don't need the trouble.
( like I said, "oozing". )
Good luck,
dave
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
