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
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "moving goal post"
-
Hey everyone,
We have a few pieces of news we're very excited to share with everyone today. Apologies for the long post, but there's a lot to cover!
First, as some of you might have already seen, we just launched the "subscribed" tab in the devRant app on iOS and Android. This feature shows you a feed of the most recent rant posts, likes, and comments from all of the people you subscribe to. This activity feed is updated in real-time (although you have to manually refresh it right now), so you can quickly see the latest activity. Additionally, the feed also shows recommended users (based on your tastes) that you might want to subscribe to. We think both of these aspects of the feed will greatly improve the devRant content discovery experience.
This new feature leads directly into this next announcement. Tim (@trogus) and I just launched a public SaaS API service that powers the features above (and can power many more use-cases across recommendations and activity feeds, with more to come). The service is called Pipeless (https://pipeless.io) and it is currently live (beta), and we encourage everyone to check it out. All feedback is greatly appreciated. It is called Pipeless because it removes the need to create complicated pipelines to power features/algorithms, by instead utilizing the flexibility of graph databases.
Pipeless was born out of the years of experience Tim and I have had working on devRant and from the desire we've seen from the community to have more insight into our technology. One of my favorite (and earliest) devRant memories is from around when we launched, and we instantly had many questions from the community about what tech stack we were using. That interest is what encouraged us to create the "about" page in the app that gives an overview of what technologies we use for devRant.
Since launch, the biggest technology powering devRant has always been our graph database. It's been fun discussing that technology with many of you. Now, we're excited to bring this technology to everyone in the form of a very simple REST API that you can use to quickly build projects that include real-time recommendations and activity feeds. Tim and I are really looking forward to hopefully seeing members of the community make really cool and unique things with the API.
Pipeless has a free plan where you get 75,000 API calls/month and 75,000 items stored. We think this is a solid amount of calls/storage to test out and even build cool projects/features with the API. Additionally, as a thanks for continued support, for devRant++ subscribers who were subscribed before this announcement was posted, we will give some bonus calls/data storage. If you'd like that special bonus, you can just let me know in the comments (as long as your devRant email is the same as Pipeless account email) or feel free to email me (david@hexicallabs.com).
Lastly, and also related, we think Pipeless is going to help us fulfill one of the biggest pieces of feedback we’ve heard from the community. Now, it is going to be our goal to open source the various components of devRant. Although there’s been a few reasons stated in the past for why we haven’t done that, one of the biggest reasons was always the highly proprietary and complicated nature of our backend storage systems. But now, with Pipeless, it will allow us to start moving data there, and then everyone has access to the same system/technology that is powering the devRant backend. The first step for this transition was building the new “subscribed” feed completely on top of Pipeless. We will be following up with more details about this open sourcing effort soon, and we’re very excited for it and we think the community will be too.
Anyway, thank you for reading this and we are really looking forward to everyone’s feedback and seeing what members of the community create with the service. If you’re looking for a very simple way to get started, we have a full sample dataset (1 click to import!) with a tutorial that Tim put together (https://docs.pipeless.io/docs/...) and a full dev portal/documentation (https://docs.pipeless.io).
Let us know if you have any questions and thanks everyone!
- David & Tim (@dfox & @trogus)53 -
I got laid off from my previous position as a Software Engineer at the end of June, and since then it was a struggle to find a new position. I have a good resume, about 4 years of professional dev experience and 5 years of experience in the tech industry all together, and great references.
As soon as I got laid off, I talked to my old manager at my previous company, and he said that he'd love to hire me back, but he just filled his last open spot.
In order to prepare, I had my resume reviewed by a specialist at the Department of Labor, and she said that it was one of the better resumes that she had seen.
There aren't a huge amount of dev jobs in my area, and I got a TON of recruiter emails. But they were all in other states, and I wasn't interested in moving.
I applied to all the remote and local positions I could find (the ones that I was qualified for,) and I just got a bunch of silence and denials from all my applications. I had a few interviews that went great, but of course, those companies decided to put the position on hold so they could use the budget for other things.
The silence and denials were really disconcerting, and make you think that something might be wrong with you or your interviewing abilities.
And then suddenly, as if the floodgates had opened, I started getting a ton of callbacks and interviews for both local and remote opportunities. I don't know if the end-of-year budget surpluses opened up more positions, but I was getting a lot of interest and it felt amazing.
Another dev position opened up at my previous company, and I got a great recommendation for that from my former manager and co-workers. I got a bunch of other interviews, and was moved onto the next rounds in most of them.
And finally, I got reached out to regarding a remote position I applied for a while ago, and the company was great about making the interview process quick and efficient. Within 2 weeks, I went from the screening call, to the tech call, and to the final call with the CTO. The CTO and I just hung out and talked about cars/boats/motorcycles for half the interview, and he was an awesome guy. AND THEN I GOT AN OFFER THE NEXT DAY!
The offer was originally for about the same amount as I made at my previous job, but I counteroffered up a good amount and they accepted my counteroffer!
It's a great company with offices all over the world, and they offer the option to travel to all those offices for visits if you want. So if you're working on a project with the France team and you think that it'd be easier to just work with them face-to-face, then the company will pay to fly you out to Paris for the week. Or you can work completely remotely. They don't mind either way.
I'm super excited to work with them and it feels great to be back in the job world.
Sorry about the long post, but I just wanted to tell my story and help encourage anybody out there who's going through the same thing right now.
Don't get discouraged, because you WILL find an awesome opportunity that's right for you. Get somebody to go over your resume and give you improvement recommendations. Brush up on your interviewing skills. Be sure to talk about all the projects you've worked on and how they positively impacted people and/or companies.
This is what I found interviewers responded the best to: Be sure to emphasize that you love learning new things and that you love passing along that knowledge to other people, and that your goal is to be an approachable and reliable source of knowledge for the company and to be as helpful as possible. It's important to be in a position that encourages both knowledge growth and knowledge sharing, and I think that companies really appreciate that mindset in a team member.
Moral of the story: YOU GOT THIS!10 -
MTP is utter garbage and belongs to the technological hall of shame.
MTP (media transfer protocol, or, more accurately, MOST TERRIBLE PROTOCOL) sometimes spontaneously stops responding, causing Windows Explorer to show its green placebo progress bar inside the file path bar which never reaches the end, and sometimes to whiningly show "(not responding)" with that white layer of mist fading in. Sometimes lists files' dates as 1970-01-01 (which is the Unix epoch), sometimes shows former names of folders prior to being renamed, even after refreshing. I refer to them as "ghost folders". As well known, large directories load extremely slowly in MTP. A directory listing with one thousand files could take well over a minute to load. On mass storage and FTP? Three seconds at most. Sometimes, new files are not even listed until rebooting the smartphone!
Arguably, MTP "has" no bugs. It IS a bug. There is so much more wrong with it that it does not even fit into one post. Therefore it has to be expanded into the comments.
When moving files within an MTP device, MTP does not directly move the selected files, but creates a copy and then deletes the source file, causing both needless wear on the mobile device' flash memory and the loss of files' original date and time attribute. Sometimes, the simple act of renaming a file causes Windows Explorer to stop responding until unplugging the MTP device. It actually once unfreezed after more than half an hour where I did something else in the meantime, but come on, who likes to wait that long? Thankfully, this has not happened to me on Linux file managers such as Nemo yet.
When moving files out using MTP, Windows Explorer does not move and delete each selected file individually, but only deletes the whole selection after finishing the transfer. This means that if the process crashes, no space has been freed on the MTP device (usually a smartphone), and one will have to carefully sort out a mess of duplicates. Linux file managers thankfully delete the source files individually.
Also, for each file transferred from an MTP device onto a mass storage device, Windows has the strange behaviour of briefly creating a file on the target device with the size of the entire selection. It does not actually write that amount of data for each file, since it couldn't do so in this short time, but the current file is listed with that size in Windows Explorer. You can test this by refreshing the target directory shortly after starting a file transfer of multiple selected files originating from an MTP device. For example, when copying or moving out 01.MP4 to 10.MP4, while 01.MP4 is being written, it is listed with the file size of all 01.MP4 to 10.MP4 combined, on the target device, and the file actually exists with that size on the file system for a brief moment. The same happens with each file of the selection. This means that the target device needs almost twice the free space as the selection of files on the source MTP device to be able to accept the incoming files, since the last file, 10.MP4 in this example, temporarily has the total size of 01.MP4 to 10.MP4. This strange behaviour has been on Windows since at least Windows 7, presumably since Microsoft implemented MTP, and has still not been changed. Perhaps the goal is to reserve space on the target device? However, it reserves far too much space.
When transfering from MTP to a UDF file system, sometimes it fails to transfer ZIP files, and only copies the first few bytes. 208 or 74 bytes in my testing.
When transfering several thousand files, Windows Explorer also sometimes decides to quit and restart in midst of the transfer. Also, I sometimes move files out by loading a part of the directory listing in Windows Explorer and then hitting "Esc" because it would take too long to load the entire directory listing. It actually once assigned the wrong file names, which I noticed since file naming conflicts would occur where the source and target files with the same names would have different sizes and time stamps. Both files were intact, but the target file had the name of a different file. You'd think they would figure something like this out after two decades, but no. On Linux, the MTP directory listing is only shown after it is loaded in entirety. However, if the directory has too many files, it fails with an "libmtp: couldn't get object handles" error without listing anything.
Sometimes, a folder appears empty until refreshing one more time. Sometimes, copying a folder out causes a blank folder to be copied to the target. This is why on MTP, only a selection of files and never folders should be moved out, due to the risk of the folder being deleted without everything having been transferred completely.
(continued below)29 -
I know I’ll get mixed views for this one...
So I’ll state my claim. I agree with the philosophy of uncle bob, I also feel like he is the high level language - older version of myself personality wise.. (when I learned about uncle bob I was like this guy is just like me but not low level haha).
Anyway.. I don’t agree with everything because I think he thinks or atleast I get the vibe he thinks everything can be solved by OOP, and high level languages. This is probably where Bob and I disagree. Personally I don’t touch ruby, python and java and “those” with a 10 foot pole.
Does he make valid arguments, yes, is agile the solve all solution no.. but agile ideas do come natural and respond faster the feedback loop of product development is much smaller and the managers and clients and customers can “see things” sooner than purly waterfall.. I mean agile is the natural approach of disciplined engineers....waterfall is and was developed because the market was flooded with undisciplined engineers and continues to flood, agile is great for them but only if they are skilled in what they are doing and see the bigger picture of the forest thru the trees.. which is the entire point of waterfall, to see the forest.. the end goal... now I’m not saying agile you only see a branch of a single tree of the forest.. but too often young engineers, and beginners jump on agile because it’s “trendy” or “everyone’s doing it” or whatever the fuck reason. The point is they do it but only focus on the immediate use case, needs and deliverables due next week.
What’s wrong with that?? Well an undisciplined engineer doing agile (no I’m not talking damn scrum shit and all that marketing bullshit).. pure true agile.
They will write code for the need due next week, but they won’t realize that hmm I will have the need 3 months from now for some feature that needs to connect to this, so I better design this code with that future feature in mind...
The disciplined engineer would do that. That is why waterfall exists so ideally the big picture is painted before hand.
The undisciplined engineer will then be frustrated in the future when he has to act like the cool aid man thru the hard pre mature architectural boundaries he created and now needs links or connections that are now needed.
Does moving to agile fix that hell no.. because the undisciplined engineer is still undisciplined.
One could argue the project manager or scrum secretary... (yes scrum secretary I said that right).. is suppose to organize and create and order the features with the future in mind etc...
Bullshit ..soo basically your saying the scrum kid is suppose to be the disciplined engineer to have foresight into realizing future features and making requirements and task now that cover those things? No!
1 scrum bitch focuses too much on pleasing “stake holders” especially taken literally in start ups where the non technical idiots are too involved with the engineering team and the scrum bastard tries to ass kiss and get everything organized and tasks working so the non technical person can see pretty things work.
Scrum master is a gate keeper and is not needed and actually hinders the whole process of making a undisciplined engineer into a disciplined engineer, makes the undisciplined engineer into a “forever” code grunt... filling weekly orders of story points unable to see the forest until it’s over because the forest isn’t show to the grunt only the scrum keeper knows the big picture..... this is bad this is why waterfall is needed.
Waterfall has its own problems, But that’s another story for another day..
ANYWAY... soooo where were we ....
Ahh yess....
Clean code..
Is it a good book, yes.. does uncle bobs personality show thru the book .. yes lol.
If you know uncle bob you will understand what I just did with this post lol. I had to tangent ( at least mine was related to the topic) ...
I agree with the principles of the book, I don’t agree with the extreme view point. It’s like religion there’s the modest folks and then there are the extremists. Well he’s the preacher of the cult and he’s on the extreme side.. but that doesn’t mean he’s wrong.. many things he nails... he just hits the nail thru the wall just a bit.
OOP languages are not the solution... high level languages do not solve everything.. pininciples and concepts can be used across the board and prove valuable.. just don’t hold everything up like the 10 commandments of which you cannot deviate from.. that’s the difference here I think..
Good book, just don’t take it as the Bible as a beginner, actually infact DONT read this book as a beginner. Wait a bit learn then reflect by reading this.15 -
Spend about half the day fixing a bug. Whilst reporting it complete on our ticket system, QA change the ticket's expected outcome. Ffs.