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
Search - "it'll be fun they said"
-
My birthday is coming up on the 13th so I'll be 17 soon, but it's a shame. I like being 16...
Anyway... I'm going to spend the entire day working on my python script because I know no one will come.
For 5-6 years no one came to my birthday even though they said they would.
It's fine. I stopped caring, besides, I get to spend the day with variables and loops! It'll be a fun day, not to mention I'll be home alone so no one will bother me.
Useless but interesting fact: I got lucky. I was born ONE MINUTE before Valentine's day. At 11:59 I would be so upset if I was born on the 14th.77 -
Come to a festival they said.. .. It'll be fun they said.. Here I'm ranting and reading machine learning algorithms under a tree, while others party. Omg.7
-
Use Linux desktop they said.
It'll be fun they said.
So much to configure.
Such fun.
18 hours later and hibernation, Bluetooth, Sound and Nvidia Optimus still not working after countless modprobes and config changes.
Hello again, Windows. You make me feel safe.
I'll just stick to Linux on servers and nothing more.41 -
TL;DR :
"when i die i want my group project members to lower me into my grave so they can let me down one last time"
STORY TIME
Last year in College, I had two simultaneous projects. Both were semester long projects. One was for a database class an another was for a software engineering class.
As you can guess, the focus of the projects was very different. Databases we made some desktop networked chat application with a user login system and what not in Java. SE we made an app store with an approval system and admin panels and ratings and reviews and all that jazz in Meteor.js.
The DB project we had 4 total people and one of them was someone we'll call Frank. Frank was also in my SE project group. Frank disappeared for several weeks. Not in class, didn't contact us, and at one point the professors didn't know much either. As soon as we noticed it would be an issue, we talked to the professors. Just keeping them in the loop will save you a lot of trouble down the road. I'm assuming there was some medical or family emergency because the professors were very understanding with him once he started coming back to class and they had a chance to talk.
Lesson 1: If you have that guy that doesn't show up or communicate, don't be a jerk to them and communicate with your professor. Also, don't stop trying to contact the rogue partner. Maybe they'll come around sometime.
It sucked to lose 25% of our team for a project, but Frank appreciated that we didn't totally ignore him and throw him under the bus to the point that the last day of class he came up to me and said, "hey, open your book bag and bring it next to mine." He then threw a LARGE bottle of booze in there as a thank you.
Lesson 2: Treat humans as humans. Things go wrong and understanding that will get you a lot farther with people than trying to make them feel terrible about something that may have been out of their control.
Our DB project went really well. We got an A, we demoed, it worked, it was cool. The biggest problem is I was the only person that had taken a networking class so I ended up doing a large portion of the work. I wish I had taken other people's skills into account when we were deciding on a project. Especially because the only requirement was that it needed to have a minimum of 5 tables and we had to use some SQL language (aka, we couldn't use no-SQL).
The SE project had Frank and a music major who wanted to minor in CS (and then 3 other regular CS students aside from me). This assignment was make an app store using any technology you want. But, you had to use agile sprints. So we had weekly meetings with the "customer" (the TA), who would change requirements on us to keep us on our toes and tell us what they wanted done as a priority for the next meeting. Seriously, just like real life. It was so much fun trying to stay ahead of that.
So we met up and tried to decided what to use. One kid said Java because we all had it for school. The big issue is trying to make a Java web app is a pain in the ass. Seriously, there are so many better things to use. Other teams decided to use Django because they all wanted to learn Python. I suggested why not use something with a nice package system to minimize duplicating work that had already been done and tested by someone. Kid 1 didn't like that because he said in the real world you have to make your own software and not use packages. Little did he know that I had worked in SE for a few years already and knew damn well that every good project has code from somewhere else that has already solved a problem you're facing. We went with Java the first week. It failed miserably. Nobody could get the server set up on their computers. Using VCS with it required you to keep the repo outside of the where you wrote code and copy and paste changes in there. It was just a huge flop so everyone else voted to change.
Lesson 3: Be flexible. Be open to learning new things. Don't be afraid to try something new. It'll make you a better developer in the long run.
So we ended up using Meteor. Why? We all figured we could pick up javascript super easy.Two of us already knew it. And the real time thing would make for some cool effects when an app got a approved or a comment was made. We got to work and the one kid was still pissed. I just checked the repo and the only thing he committed was fixing the spelling of on word in the readme.
We sat down one day and worked for 4 straight hours. We finished the whole project in that time. While other teams were figuring out how to layout their homepage, we had a working user system and admin page and everything. Our TA was trying to throw us for loops by asking for crazy things and we still came through. We had tests that ran along side the application as you used it. It was friggin cool.
Lesson 4: If possible, pick the right tool for the job. Not the tool you know. Everything in CS has a purpose. If you use it for its purpose, you will save days off of a project.1 -
Have children and build a house. You will forget what you enjoyed doing in your free time. Because you will not have any more!
P. S. I could have attached my github activity graph instead, but that is even more embarrassing 😭7 -
First time rant here, and I'm just gonna let fucking loose because this seems to be a good place for it.
My uni can't teach programming for shit. It's the reason people sign up for the course. They want to know how to program. I'm self-taught and unhappy in college as it is.
I joined CS because I thought they'd assimilate work in the real world, which is experience I need. I realized early on that programming is like art, and I love the rush I get of something finally working right.
That said, they sucked the fun out of it. It's too structured. Everyone trying to get the same goddamn result. In the real world, we'd be working on a larger project that involved planning, design, communication, teamwork, and the ability to complete each of our own pieces of the puzzle and subsequently put them together in a project that works for the end user.
I'm paying to be a fucking sheep, people. Why do employers give a shit about a degree instead of talent? Welp, fuck society for this. You can tell me I can drop it and still get a good job, it'll just be harder. That's the fucking problem. I can't get a job if these incompetent fucking bastards will throw out my resumé the moment they see "self-taught."
If we could hire based on GitHub contributions, I think many of us here would be relatively better off. Programmers program, not socialize. We do socialize, but in our own little groups. We team up as needed. The moment the jackass in HR realizes that, the better off we'll be.
Sorry, just the way I'm seeing shit right now. I'm going through some OCD-induced depression and this might be a result of that, but I'm passed the point of giving a fuck.15 -
Come to the new year's party, they said.
It'll be fun, they said.
We'll leave you alone, they never said. -
Build a testbench they said, it'll be fun.
Guess who just reversed the direction of the pump.
Pumping into the reservoir from the reservoir isn't such a great idea.
😡 -
Start a business, it'll be fun they said. One of those days you'll realise that you're in a situation where you'll have to fire a friend from your engineering team, there's no way around it..
People keep on thinking and saying
"You're so lucky, you can choose the clients and the team, and work whenever you want to.."
Yep. Highest highs and lowest lows go hand in hand. Thank god there's both.2 -
Use alpine, they said. It'll be fun, they said. Spent ages trying to figure out what was wrong with my fresh Docker swarm. I tried everything, then I noticed that nginx was calling some random IPs instead of the web container's. Turns out the alpine image doesn't have a library that would properly resolve the IP of the container. I replaced it with the main nginx image and it's working perfectly 🙄
-
I'm in a big fat fucking stinking rut, as in progress on this project has absolutely stagnanted.
Gonna rubber face your duck now **UNZIPS** excepts I don't have zippers, as joggers are the one true way; fake Adidas til I fucking drop.
Brain damage aside, I understand both how I've layed out the data and what I'm supposed to do with it. We have a virtual machine, an array of instructions and arguments for a given process within it, and we need to walk this array and map values to registers.
We also need to spill values inside registers to stack, IF they are required at a further point within that block. This also isn't terribly complex. We simply look forward in the array and see if the value is an argument to any instruction that *needs* this value to be loaded (ie, within a register).
So this implies multiple iterations; we need to better understand how one particular value is used throughout an F before we can make a final decision on how many registers and stack space are actually needed for the whole block.
Here's where it gets tricky. If there's a call, we need to be certain that the symbol being invoked has already been fully processed. Besides the obvious fact that recursion fucks me up, there's another matter: say a private method gets invoked by another private method. We can take advantage of this, by which I mean, sacrilege incoming so put on this toga.
Looking at the output for C compilers, it would seem this is not done in practice, I would assume because it's a pain in the ass. But when you have the guarantee that F will only be called internally, as that's what "private" means, there's two ways it can go:
0. It's well below the 13-20 cycle threshold, so you inline the fucker. No suprises there.
1. It's a more involved affaire, and invoked in more than one place, so you don't inline it. Codesize matters.
Recursion and [1] are the big deal things holding me back. Not because it's too hard, like I said this is kindergarten level abstraction. I'm just slow and fanatical, which is how I prefer to spell "constant obsessive paranoid delusions". I can see the potential optimization I can pull here, so I'm stuck trying to figure it out.
Idea would be, handling the register allocation and stack spill for an internal-internal (or deep internal; what we like to call a "guts" method) in synchronization with the *calling* processes. This is, fundamentally, violating all conventions -- but so under the hood no one will notice.
Let me give you an example. If we were to pass some value to a function, expecting to mutate it and get a different value back, in a lot of cases it'd be stupid to make an implicit copy by using two registers, one for input and another for the output. Dude, it's one cycle. Multiply it by a million, say sixty times per second, for every time you __needlessly__ make a copy of a value that we've already stated is mutable.
Clearly unacceptable. This is, in the strictest sense, everywhere in every single codebase. Premature micro optimization is the root of all goodness, God is great and praiseworthy. So how do we go about it?
Answer is I know and I don't know. By which I mean to say, this very thing I've done by hand. Assembly is fun. Now the issue is teaching a calculator how to do it. Not so fun.
There is a dependency chain between processes, as I believe I've kind of alluded to. I'm trying to make decisions on the side of the caller depending on the details of the callee, which is why recursion is rawdogging my soul. This is the same situation, it's inverting the direction of one or more links in the dependency chain, which makes no fucking sense.
And yet it does.
Brain, explain yourself.
How do *you* handle this without crashing?
Brain?
<<ME STEWPED; BEEP-BOOP>>
Alright then, that was a useless attempt at fuckery. Let's have a nap then, maybe it'll come to me in the morning. That's what I've been saying to myself for almost a month now.
Perhaps it is a hardcoded fuk.1