|
Had a simple audio edition task, and of course, used Audacity[^].
This piece of software has been constantly amazing in at least the last decade. Easy, lightweight, intuitive. I had my editing done in no less than 2 minutes. Awesome.
|
|
|
|
|
I know what you mean - good kit!
Now, if only there was the same for video - I have about eight different tools for that, each of which is good at one thing and weaker at the rest. And none of them work the same way, and some of them won;t work with this format, or that size, or won't output the other, ... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
The gopro studio is good and easy to work with, but very, very limited with the file formats...
I also use windows movie maker and I have used adobe premiere to some extend. But indeed 1 good tool, I have not found yet.
|
|
|
|
|
I find it just a little ironic that we have programmers complaining that there's no decent software available for a given task.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
 I was not complaining, I just wanted to say that the programmers really did a good job there.
As for programming SW that I need, well, even if I think I am a decent programmer, it would have taken me at least two months to programm a draft of something like audacity vs. 2 minutes with using it. So...
|
|
|
|
|
I use it to sample the cassette tapes from my old computer. Then I run a program over the samples and reconstruct the original binary data. It works even with tapes that don't load anymore.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
|
I can even write new programs comfortably on the PC and then generate a WAV file from binary which can be played to and loaded by the old computer.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Audacity is amazing! I use it for compression, removal of pre/post recording noise, fade in/out and ducking of raw tracks that I've record on my multi-track recorder. I then bring the Audacity processed files back to my recorder for mixing, effects and mastering. Here's[^] one result - if you're into classic rock. 
/ravi
|
|
|
|
|
For me, Audacity is the best software when it comes to audio making, editing etc. Been using it for years and it has every feature that I need.
|
|
|
|
|
What are your tips for showcasing Back-End Dev. work? Especially work where I only did the back-end. Front-End is easy: You just show them the website or photos of it, which illustrate the UX/Photo/CSS/HTML work... However, with me doing BACK-END dev, the site can look like ass but my work is actually quality work (making it more secure, faster performance, scaled, designing the DB, etc...) because I only did the back-end of things...
Not to mention, clients who view my LinkedIn and other Portfolios may not understand or want to understand the actual coding part. Front-End appears at first to lend itself to easier marketing techniques due to this, but I am sure there are workarounds for this that I haven't thought of. I am open to suggestions! Thanks!
|
|
|
|
|
If you are able to, throw the work on github. Then in the readme file on github write a high level outline of what the code itself is/does that is fancy with little snippets and why it is quality code/what the current "normal" way of achieving the functionality you've implemented on the backend is, then why the way you went about it is better.
This way those that want to dig into your repository and see all of your code can do so while others who are satisfied with the readme don't have to figure out why your backend code is fancy.
|
|
|
|
|
TheOnlyRealTodd wrote: Front-End is easy: You just show them the website or photos of it, which illustrate the UX/Photo/CSS/HTML work...
Unless you're in the medical industry and it's heavily regulated and they don't want screenshots available to the public.
Jeremy Falcon
|
|
|
|
|
Or the banking industry, which makes even getting the source onto github nigh impossible in the first place. One major bank (JPMC) won't even let employees reveal they work there.
|
|
|
|
|
Coming from the standpoint of someone who's given tech interviews... I'd agree with the github or equivalent thing. But rather than release your old company's IP to the wild, why not just build a side project to showcase your skills? Then during an interview just talk about your projects and also mention that if you haven't already. That would work for me.
Jeremy Falcon
|
|
|
|
|
That makes sense and it's what I've done. Its just one of my associates is trying to get me to "talk more in plain English," some clients we may have don't even really know what back-end is, but they do actually NEED it... if that makes sense. It's hard to show a client who doesn't understand code at all what we do... For example, a MySQL site may look and fell exactly the same as a MS SQL Server site, or a MVC vs MVVM, etc...
I guess I'll just have to use plain English to explain the concepts as simple as possible.
|
|
|
|
|
For those that you want to explain your tech stack a little more in depth. In your example you could explain the cost savings of mysql vs other databases (ex: sql server). Everyone enjoys hearing how they can save money.
With MVC frameworks you could detail how it is in theory easier to maintain due to separation of concerns and in turn, easier to have other developers working on the code base.
|
|
|
|
|
For most people, tech stacks are gibberish. Only techs care about that at all.
Jeremy Falcon
|
|
|
|
|
I'd say the best bet is to know your target audience. Are you talking to an interviewer that understands tech? If so, chat about it all day long. Are you talking to a business guy that has no idea about tech? Then he won't care about XYZ at all. So your friend is right.
If it's a business type, they live and breathe on reports, reports, reports. So think metrics. Print out a report on how your backend code, reduced cost by blah blah, or made this such and such improvement. You can throw in a pie chart with that. Just put yourself in the seat of a person who is a business type of person with little tech know-how. How would you want to be sold?
Jeremy Falcon
|
|
|
|
|
I agree whole heartedly with this.
Also if you've done something that solved a problem in a neat way you could always write a blog article demonstrating it in a way that does not reveal and company specific ip.
Even if nobody reads that blog it'll be there to show a prospective employer in the future.
|
|
|
|
|
Start your own website and showcase your "Back End Work" 
|
|
|
|
|
In some scenarios, queries or spreadsheets of raw, unprocessed data, and the same of processed data, the in between data, and a thorough write-up of what happens to the data, can help a bit. I've only ever shown people query results in person though, and not had to transmit said data elsewhere.
Do what thou wilt shall be the whole of the Law. - Liber AL vel Legis 1:40, Aleister Crowley
|
|
|
|
|
If you have been paid for the work and do not own it, you must not make it avaliable publicly.
|
|
|
|
|
Perhaps describe your work to a perspective customer using an analogy. Maybe a house: foundation, electrical, plumbing, etc. This way you can stress the importance of the "unseen" parts of the program using something they can visualize. You can make equivalencies about the design, ease of maintenance, ease of adding enhancements, etc. I have used this very effectively in the past. Pick your own analogy. They still won't know if your actual code is any good, but that's where references and some of the other suggestion made by others here will help.
Mike
|
|
|
|
|
Do a little video that explains in simple terms what your work is about and (without mentioning names) they way you have improved a certain project's quality.
Check this example:
Server Virtualization with VMware vSphere[^]
They show you what this product do in simple terms in a short video. It doesn't give technical details but invites you to know more.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
