Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I've learned that trying to jump into a project without properly understanding everything it will entail is bad.
I recently worked on a project that involved modernizing a legacy system and no one on the team (including me) fully understood how the legacy system worked. This led to us missing a lot of edge cases and attacking the project in a way that really wasn't beneficial overall.
If we had thought about the entire system beforehand and mapped out the legacy system, the project would've turned out much better.10 -
Had three servers running in prod. For extra security all of them were encrypted (hdd encryption) just in case.
"mate, servers need a quick reboot, that alright?"
Me: yeah sure!
"oh hey they're encrypted, what's the password?"
Uhm.....
😐
😓
😨
😵😨😮😧😫
😲😶😭
Yeah, i also forgot to turn on the backup process...17 -
Funny story about the first time two of my servers got hacked. The fun part is how I noticed it.
So I purchased two new vps's for proxy server goals and thought like 'I can setup fail2ban tomorrow, I'll be fine.'
Next day I wanted to install NginX so I ran the command and it said that port 80 was already in use!
I was sitting there like no that's not possible I didn't install any server software yet. So I thought 'this can't be possible' but I ran 'pidof apache2' just to confirm. It actually returned a PID! It was a barebones Debian install so I was sure it was not installed yet by ME. Checked the auth logs and noticed that an IP address had done a huge brute force attack and managed to gain root access. Simply reinstalled debian and I put fail2ban on it RIGHT AWAY.
Checked about two seconds later if anyone tried to login again (iptables -L and keep in mind that fail2ban's default config needs six failed attempts within I think five minutes to ban an ip) and I already saw that around 8-10 addresses were banned.
Was pretty shaken up but damn I learned my lesson!8 -
"It is just a small task. I can do that in just..." Never ever ever say the above statement even if you are 10000% confident.5
-
Couple years ago, I wrote a game in assembly.
Yesterday, I tried to look at the source, and realised there isn't a single fucking comment.9 -
Can't find the bug for hours. Next day find it immediatly.
Sometimes try and get some distance to your code.4 -
Do NOT be overwhelmed nor discouraged when you realized how little you know.
after all software dev is still a work in progress :)6 -
"I don't need to comment my code because I will remember what everything does/stands for later..."6
-
Qualification != proficiency
Worked at a company where this bloke (Jepediah mcShitFart we shall call him) had enough programming certs and qualifications to fill a page.
I was the one fixing his fuck ups, because he coded like his ass, debugged like his ass, talked like an ass, and used to shrug off responsibility like an ass. Hr did nothing because he 'was a long time employee'.
Plus, I have met hundreds of programmers who would put many to shame, and they don't have a single qualification.10 -
When given a task, don't start working immediately. Think about it first.
If it is taking too long, don't just persevere, stop and think why.
You are paid to think, not type.13 -
The importance of version control. Had a school project at a real company and i didn't understand it so i said fuck it. Then someone asked me to alter the js library a little and push/pull that to the server. I thought fuck it, altered it and accidentally pressed save (automatic ftp upload). Suddenly the file was overwritten (that guy worked on it for 6 fucking hours) and it went from like a thousand lines to just a few. We did restore it from the browser. He said: either you're going to use git or you're out.
Then i started using git.4 -
That you should always admit you make mistakes and learn from them, instead of acting like you know everything arrogantly.
-
A long time ago on a project far far away, I didn't realize there was a src folder, and made my changes in the build folder instead... And to makes matters worse, I asked a co-worker -- an ex-Googler -- for help with the issue I was working on.
Rarely have I been more embarrassed.1 -
Never do something technical for free. You end up being treated as the responsible person for batteries even if your actual profession is web development.9
-
If your manager asks for a "rough time estimate" for a project, there is a higher than 99% chance that your answer will be written down and be used in presentations of project roadmap to upper management and/or marketing, who will create a hard deadline based on your rough estimate and communicate this to customers/clients, and then blame you for not keeping the deadline when it turns out (as it always does) that the rough estimate was off by several months because feature creep caused by upper management.3
-
No matter how much product owners claim "bugs have priority over anything else", "we value high quality structured code", and "we do test driven development"...
...Once a big client wants a feature to be developed before they sign up, dirty code will be written from napkin specs, and that code will always be refractored "soon".4 -
Always make smaller commits! Easy to roll back, easy to cherry-pick, easy to debug when identifying when something went wrong.2
-
Never jump on to the framework bandwagon.
Use the frameworks that you really want to use.
I'm looking at you, JavaScript frameworks.2 -
If they immediately agreed to your salary expectations, either your expectations were low or their expectations were high (or both).
-
Commit fast, commit often.
I lost a day's worth of code once, because I wanted to commit all of them in the evening right before I was to go home. Then I mistakenly hit `git checkout .` instead of `git add .`.
Poof. Gone.9 -
One of our newly-joined junior sysadmin left a pre-production server SSH session open. Being the responsible senior (pun intended) to teach them the value of security of production (or near production, for that matter) systems, I typed in sudo rm --recursive --no-preserve-root --force / on the terminal session (I didn't hit the Enter / Return key) and left it there. The person took longer to return and the screen went to sleep. I went back to my desk and took a backup image of the machine just in case the unexpected happened.
On returning from wherever they had gone, the person hits enter / return to wake the system (they didn't even have a password-on-wake policy set up on the machine). The SSH session was stil there, the machine accepted the command and started working. This person didn't even look at the session and just navigated away elsewhere (probably to get back to work on the script they were working on).
Five minutes passes by, I get the first monitoring alert saying the server is not responding. I hoped that this person would be responsible enough to check the monitoring alerts since they had a SSH session on the machine.
Seven minutes : other dependent services on the machine start complaining that the instance is unreachable.
I assign the monitoring alert to the person of the day. They come running to me saying that they can't reach the instance but the instance is listed on the inventory list. I ask them to show me the specific terminal that ran the rm -rf command. They get the beautiful realization of the day. They freak the hell out to the point that they ask me, "Am I fired?". I reply, "You should probably ask your manager".
Lesson learnt the hard-way. I gave them a good understanding on what happened and explained the implications on what would have happened had this exact same scenario happened outside the office giving access to an outsider. I explained about why people in _our_ domain should care about security above all else.
There was a good 30+ minute downtime of the instance before I admitted that I had a backup and restored it (after the whole lecture). It wasn't critical since the environment was not user-facing and didn't have any critical data.
Since then we've been at this together - warning engineers when they leave their machines open and taking security lecture / sessions / workshops for new recruits (anyone who joins engineering).26 -
Always use SELECT-query with the same conditions before you DELETE/UPDATE in a production database.1
-
Ask for help, it's not a sign of weakness. I've missed way too many deadlines because I've been too prideful or overly
ambitious. -
I am officially hired as an Associate Business Analyst ! I made an internship as an Analyst Developper and the company enjoyed my work so they ask me if I wanted to join the team ! 🎉6
-
Even if you think it will make the app better and more intuitive. The customer didn't ask for it. Period.7
-
Plan before you start a project (write pseudocode, draw a small diagram, research other implementations, etc). Without a plan, those projects are usually the ones that turn out unfinished.1
-
Things will always take longer than you expect, even when you take into account Hofstadter's Law (which is that things will always take longer than you expect, even when you take into account Hofstadter's Law).3
-
Before shutting something down, verify that its the right one ;)
A colleague was testing some performance setting on a server and needed to restart the network driver so he disabled it and was going to enable it when the remote session died ;)
Fast 30 min trip to the datacenter to enable network card.2 -
Never ever have a tab open on production server database. Changed all users passwords by mistake. Thought was my test database.2
-
Sometimes dirty code is more efficient than clean code.
If features get dropped frequently and requirements change every few days, writing best-practices, tested code is wasted time. Learned that in my first job where I thought the other devs were all bad. Until I realized their bad code pays my salary, and my clean code takes more time to develop.6 -
Always use an editor with color syntax highlighting. About 20 years ago I spent 3 days and nights debugging something that was a simple typo error. Since then I always use an editor with color syntax highlighting.7
-
Never accuse a co-worker of making a really stupid change to your code unless you know for certain that they made the change instead of you.2
-
Boasting you know programming just because you watched some programming videos doesn't help in any of the case, I learned this the hard way because I tried to show off in front a girl and turned out, she knew more and better. This was when I was 14, very bad memory14
-
Always triple check which drive you are about to format. It may sound dumb but there are some people (like me) who had to reinstall the whole os because of that.6
-
Installing Windows after Ubuntu is not the recommended process for a dual boot Windows and Ubuntu system, but it is possible. 😂6
-
Threaded API Calls, or rather:
How I killed five server instances in one shot..
Creating 50000 Threads sounds like a good idea in general, the bad part starts when you use start() in a for loop to run them all at once.
No further comments your honor...7 -
No matter how hard requirement look or the thing you're going to develop JUST START THAT SHIT it will take time but you can and will do it.
-
Making a small update to an ionic app then spending a whole day trying to figure out why a button doesn't work. Tried everything to fix it and got no error messages.
Finally discovered it was because the button was inside a label and not a div.
Yeah, fun times. -
If you ever get a problem with your Linux,
DO NOT EVER try out an answer on any random forum without reading all the comments/replies.
The problem spreads like a freaking wildfire and you will end up reinstalling Linux and losing data what wasn't backed up. (If by God's grace, you do a regular back up)2 -
Don't get mad / frustrated / angry at stupid people, you're just punishing yourself for their stupidity
-
MySQL databases beginning with "test" in the name gives even people without login full access to its tables.
Somebody deleted all tables so we had to get a backup from out hoster.
Thanks MySQL.1 -
The cool little startup that hired you right out of college/university, that promised your work will be recognized and well compensated?
Well, they'll end up complaining on why you don't work more than 60 hours a week on shit pay, force you to work at the "office" (read here one of the partner's basement), and retain your vacation pay from your last paycheck. That's not cool and also illegal here.
It's been 10 years and it still infuriates me when I think about it.4 -
I'm a perfectionist and like things done the right way, but had to learn to let go and remind myself it's the clients site and their choice. No amount of logic and reasoning is going to stop a hellbent client from wanting the dumb things they want, even when it's bad for design, performance, usability and/or SEO.1
-
Using mongodb for one product
A colleague as experimenting with elastic search (I think it was).
It installed a proxy around the collection to get all events for the external search storage.
Worked well, but it was just a test so once done we removed it
But thats where it got scary.
When we removed the proxy through the search dashboard it dropped the underlying collection of live data!!!
A collection it did not create.
Hows that for bad UI.
Always experiment on a separate db server. -
-Be a university student
-Work with SCR(OT)UM for the first time
-Divide tasks into 3 day sprints
-Watch the SCRUM master go nuts and the project fail
Never again3 -
Don't trust people. Especially if they say: "No Problem, I'll invest enough time to make x happen"
But in general. Don't trust people until you know them very well. -
there is always somone smarter then you doing this shit.
Also, wait a week after you hear bright ideas from manament, and don't start work untill then.1 -
Being thrown in the deep end, baptism by fire is the best/worst way to learn a new codebase
Its not appropriate for everyone but it weirdly works -
Never start watching a series while gradle is building. You end up not finishing coding your app on time instead you watch a whole season before you get back to coding.3
-
Think twice code Once, if I had a cent for every time I've jump right into the code without a proper analysis or design just to notice that my whole implementation is not functional or scalable I'd be a millionare1
-
There's nothing more horrifying than seeing the code made by Java Swing. Good luck trying to find label1X5zPotato and what it does.
-
Not only are you not your job, your job is not worth taking home with you; unless it's actually your company, leave it in the office. You can love your job and still have days when you hate it, or days when you'd rather be doing anything else; that doesn't mean you don't still like what you do.
As a profession we can all be obsessive and not take the time out that we need, so make special effort to do so, even if that just means you're working on a personal project instead. Your brain, and partner, will be glad that you did. Whether you like to admit it or not, everyone needs downtime.1 -
Always check the licence when you include a new library.
Very nearly GPLed a large amount of commercial code by not checking this in one of my first projects out of uni.
Luckily someone else noticed and the library in question turned out to be dual licensed so it turned out ok in the end. -
Do not change username in win10.
Messes up ownership.
Ex) You have set your username as Loren. Used computer for a while. Installed bunch of programs.
Then you change your u.c to Ipsum. Some installed programs adapt to new u.c. others dont. New programs set the installation folder to either c://Loren or c://Ipsum making chaos.
Then the computer gets messed up.
...........
Opens Git Bash.
Ipsum-blahblah ~ git blahblah
Close it.
Open again
Loren-blahblah (uhh!)3 -
Learning through documentation.
I learned one thing.... That how I can copy paste any thing in my code and comment it as "magic happens here do not touch."
Yeah thats my code learned from documentation (image below )
-
Think before you do. Both in life and while developing it'll safe you time.
You should also try not to overcomplicate things.1 -
If you ask yourself "hm, what does this button do?" while on an important project: DO. NOT. TOUCH. THIS.
-
As much fun it is to code and create new features for users. Take a break from the computer and spend time with real people.
A few years ago I would stay at work to get tasks done. While everyone in the office would go home I would stay and finish some task. After doing that for a few months my wife started to yell at me.
It made me realize that no matter how important a new feature, a bug or optimizing code is family and the relationships you have are more important.4 -
This wasnt i thing i learned, rather a thing i taught someone.
It doesnt matter that you are in love with x language and you want to devote your life to it if the industry adapted something else, you will have to compromise.
(Node vs php)1 -
Dev lesson learned the hard way. Never rm -rf with wildcard arguments... If you think you're being clever it probably means you're about to mess up some shit.3
-
Take your time with merge conflicts, and put the entire file in another editor in case you really mess up.2
-
Trying to develop Java applications in Windows...
sed s/Java applications/anything/g
'sed' is not recognized as internal or external command, operable program or batch file
*sigh*3 -
I use /tmp for random stuff. So if i forget it, it gets deleted when I shut down my PC.
Its really effective against data cluttering.
But NEVER use /tmp for code testing or even new projects!1 -
Objective-C is an awful programming language that nobody should ever use for anything.
Also you dont know how important unit tests are until you have to deliver an enterprise level application without them.
Biggest one Ive learned recently, managers will promise you the earth to keep you around as long as possible, and they will go back on every promise and call it a "change in priority" -
Put everything on paper, especially if money is involved.
Did a few freelance gigs that ended in big disputes. For example, people that think you make a website from scratch in less than 2-3 hours and accuse me of charging too many hours.
Best one was a "friend" who asked me to build a site, after more than 6 months of making "changes" that were actually updates without seeing a dime. I gave him his last chance and terminated the host. Still holding the domain name :)2 -
Run the tests before you commit, even if it was just a minor modification.
(Yep, I broke most of the tests by changing only a couple of lines. Lesson learned.)1 -
No matter the hard work you want to do, how much time you want and really spend to complete something, always a scumbag project manager will set the dates so that you won't make it in f*ing time!! Really now, it is frustrating!!
Well, I moved to a new company and all seems vanilla. But you know. Now I have this lesson to remind myself.4 -
Never use random non-reversible git features on your 3-month project's master while just assuming and not actually knowing their functionality.
Or to avoid that altogether: Don't drink and git.1 -
Commit functional changes separately to code quality changes
Otherwise I'll make you do it all over again 😤 -
Biggest lesson learned for me was believing some guy wearing a comb over & a fake tan who sounds like a car salesman. He claimed selling web app services to companies was no different than selling cars. It turns out that a lot of investors were not too happy that the company went under (b4 anything was released) b/c the CEO/CFO somehow managed to burn several million dollars on first class flights, cruises, 5 star restaurants, a luxury company car (for himself), hotels, etc.,. oh and even some fake tans!
Worst part about all that he wasn't even worth sueing because he had no money after all that. He even signed the 'company' car over to one of his kids!3 -
Don't check in a major/ groundbreaking change a day or two before sprint demo! However confident you are about your code just postpone it until after all sprint demos 😷
-
Probably posted this before but don't ever put swear words in log statements because you will miss one and if you're client has a log monitoring system it will catch it, it's fairly embarrassing when your client says "we noticed quite a spike in 'bollocks' around 3am when the reorgs are happening on the database".
-
REST apis. More than you think it is.
Just because you can access a resource by a uri, doesn't mean you have a good api.
Hypermedia that shit and let websites reuse your links from api responses, then we are getting somewhere.
Also, Fucking api versioning.. Learned the hard way that /v1/ doesn't mean Shit in most cases -
During requirements gathering:
Listening.
Writing requirements as stated.
Not designing in my head.
Asking leading questions that validate said faux design. -
You cant be a recognzied as a good developer, untill you are a good tester or say produce least bug free code. You should do thorough testing of your code before handing over to QA. I lacked the skill of good unit testing, so have suffered alot in past years.1
-
I used to wipe server data before avery update because i had population script for product.
One time i wiped data and had not remembered that we had allowed users to register in the previous release
I now take backups seriously -
This is just a sweet little harmless block of code, why should I unit test it?
3 months later...
Bug in production : This is why. -
Always check if you are on the test or the prod system at least 1000 times before cleaning up the customers database.
This happend twice to my team.... At least our customers admins were pretty chill and said they learned something from this. -
Ok worked really hard and understood how to use this tool today
*Next Day*
Welp its old now time to learn the next 'new' tool 😄1 -
What is easy to code at the moment isnt necessarily the best code in the long run.
- From the dev currently maintaining spaghetties of spaghetti code -
There is a big difference between IT and CS, the first has a lot of monkeys because most of the hiring managers don't ask technical interview questions that screen out monkeys... Probably because.... **Hmmmm thinking of a nice way to say it** They don't know any better...
-
Tried to build a simple HelloWorld with Spring-MVC. After 6 hours still failed to configurate all Tomecat, Ant and Spring files...1
-
You don't need all IDE's together in your system at all times.
Burned my system's motherboard due to overload. -
I learned very quickly that magic globals are baaaaad.
I mean, it's easier than using a queue for passing data between threads, right? -
Well, I have only one:
When programming an Arduino, unplug the power cable. I nearly burned my Arduino Uno once...1 -
Let's start the project all over again - I haven't written a lot...
rm folder --force
..Wait, I may have reused the Models...
-
There is a moment in a project where you either tell everybody that they have fucked up everything and a new beginning is necessary... Or you will be the one who's getting fucked in the end as 'the constant warnings and delays were communicated, but not offensive enough to be of major importance.'
-
sudo rm * ../assets doesn't delete all files from the assets folder... (I was sleepy at this moment)
-
Always test your code, especially if you did a commit to master on Friday afternoon. Otherwise, you will end up deleting thousands of vms.
-
There will always be times when you will need to understand/modify horribly written code, or have to work with a fellow "programmer" who is clueless about what programming actually is.
In such situations, not losing your cool is a necessary evil. -
How my mind operates when someone starts looking at my code while I am coding.😂😂😂. Dev lesson "Never let anyone stare at you/your code while you are coding".
-
- never push to prod on friday or before lunch time
- doublecheck fucking everything
- test your code before and also after you push it
- you remember yesterday your colleague/boss/pm told you his part will be done by now? well guess what, its not! it never will be... -
Do NEVER give Linux-Mashines similar hostnames!
Had it often enough: forgetting I SSHed into my Laptop (ArchLFK) or RPi (HomePI) and tried to execute commands for my PC (HomeLx).
It drives you crazy when your commands do not work as desired or changes are not visible. Then you realize you're on the wrong mashine. 😰
Its like searching for your Smartphone while having it in your hand.2 -
Take a break sometimes. Go outside in fresh air and explain the problem to your self out loud. Doing this has made me ask myself the following question many times: "Why the hell have i just spent hours working on this problem and not realized this simple solution?"
-
Don't trust someone as counterpart if he says he doesn't know anything. Maybe it's not just a joke...
-
There is no perfect UI design, so stop trying to make one. Get an MVP out, fast. Design will improve with time.1
-
My top lesson was realizing that I am a stubborn person, and that I was wrong to keep trying to implement unimplemented features past a deadline and that I need to understand when to give up. I also learned that I can't trust others to finish their part of something I start. There is nothing like seeing the entire backend you wrote be gutted by someone else because they "needed to learn how route handlers work by creating it themselves" and then seeing them not complete said route handlers.
-
Wiping your whole data, including your soon-to-be new OS zip before flashing your first custom ROM on Android
-
Always have a roll forward plan, backups, and a site B. Especially if you think it is a non critical system.
-
Always double check the code you're sending to the teacher after finishing a school project.
I once sent them an old version of the code that had useless comments and debug messages everywhere. Some of them "politely" pointed out the fact that I really hated the subject, that it was pointless and that the assignment was way overcomplicated for first year students.1 -
If you don't know what you're doing, ask. If your team lead doesn't help, go over their head. You should alwats know what you're supposed to be working on, towards, whatever. If no one knows the mission and vision then leave.
-
You should write comments in your code, and in case of Perl you must write comments in your code.
I've done some DNS zone editing stuff using Perl's magic around 4 years ago and now I have no fucking idea what's going on in there. It's on production DNS server since then, no problems so far... -
Commit every change, all of them... Yes the "Forgot a ; " MUST be commit... Commit in the DEV branch... Because you aren't ready for the PRODUCTION branch... And backup every night after work...
-
Do the design first and make sure you get it reviewed!! If the reviewer is always too busy to look at your design, remind them that you can't start the actual coding until they do the review and go over it with you. And be open to their suggestions, it may save time later down the line.
-
My team leader (Indian) asked me, in my second month in the job, to estimate the required time for testing some screens.
I made the estimations based on my experience and understanding of "screen testing" then discussed it with him and he accepted the estimations.
When the time came to start the task, he sent me a document about writing automation test for the screens,which was new thing to me.
The task took more than the estimations (3 times) and I have been blamed because I made wrong estimations.
The team leader was the one who blamed me!!!
Never estimate a task without full description...2 -
Every place you work has that one person who seems to make everything difficult. It's better to be that person's friend, even if you disagree with 90% of what they do.
Sometimes, you are that guy. -
Confucius - "Study the past, if you would divine the future"
This also apply to many things in life. -
Just because you are new from university and don't understand the stuff this oh so very important senior developer does, does not mean he is doing a good job.
Latest when he leaves the company and you stay behind maintaining and extending the project you will notice...3 -
When you are changing and updating your code update your comments/docs also, there's nothing worse than getting confused by someone else's code to find that the comments/docs are wrong
-
Always use explicit parentheses.
Nothing like an OR swallowing the majority of your conditions to get you to make sure they're grouped properly with parentheses. -
If someone has more tenure than you, they dont push 'stack busting changes', your code simply failed to account for the future. 😂
(This is why my former employer is my former employer) -
That it's better to get started with git and GitHub with your own projects rather than swerling your head around someone elses code. Once you are comfortable you could try the latter.
-
my lesson as a new dev was when the senior told me to RTFM....by not using Google... as in ... real books... dusty... old... valuable... and BIG mother farking ones.2
-
Tried figuring out why my console window did only put out text sometimes, tried to figure that out for about three hours. Turns out visual studio redirects console output to their own console window by default if you start it in debug mode.
Lesson learned: The second answer on SO which is not marked as correct might be correct for you. -
Never assume.. coding, how something works, someone knowledge on something, etc. never assume anything it will come back to bite you down the road.
-
Always check your logic for non trivial modules or functionality before you write the code. It may take some time, but you can find a lot of possible errors or missed cases if you first put your logic in words...
You also get free documentation for your code if you write it as indented comments :) -
Discus always before how much ur client have to pay! Worked round 3hrs each day on a range of 6 weeks (6d each week) on a gameproject. After i did my work i requested my money - all i got were 50€! Just fifty fucking euros for so many time! Good that the retards never got it launched because my client (is even a dev) never finished his work or whatever.
PS: Didnt got paid in BTC 🤐
PPS: it was about 2,5yrs ago 😎 -
Always watch all committed files so you don't push the local config file to QA and suddenly the client have errors all over.2
-
Pushed the code without compiling. We weren't generating builds before merging the code back then. It was so embarrassing
-
When you saved a file at the wrong directory, IMMEDIATELY REMOVE IT. I have continuously lost my work by opening a file previously saved in the wrong place, overwrote the new ones, only to realize that it is a file wrongly saved a few days ago.
Also, the hours I spent trying to debug something only to realize I've overwrote a file I saved at the wrong location...2 -
Losing data if I don't start backing up my important data
Yeah, it hasn't happened yet, but I have a feeling I'm getting closer -
Rant from the past: when I was 16 I worked for a small company that had about 12 projects they worked on and maintained for local businesses...our svn was Dropbox.
-
String sql = "DELETE FROM TABLE ";
conn.ExecUpd(sql + request.getParameter("recordNumberParam"), true); -
Began working on an old project at work today. It has been about 6 months since I last touched it and 10 months since I began working here. No one that works here knew how to get the project running on anything other than one specific computer in the office...i work remotely. So instead of remoting in I finally figured out how to run it on my computer!
*crash*
Turns out it only runs on vista.... -
Minimise (or if possible, eliminate) free-text interaction in deployment scripts. You *will* type in the wrong value.
Top Tags
Weekly Rant
View