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 - "code portability"
-
Hello fellow coders can you help me here plz.
I'm really confused whether to buy MACBOOK PRO 13 INCH or SURFACE PRO 4. Both of i5/8gbRam/256ssd specs. Price almost same in India.
My main use is programming ( web apps/ open source) + portability.
Factors I like in macbook pro:
1) unix based
2) best service here in India ( heard from answers on Quora )
3) DURABILITY ( heard from answers on Quora ) ( will last for many years without any glitch).
Factors I like in Surface pro 4:
1) its ultraportability
2) pen & touch
3) better typing experience ( since I code/blog for long hours)
4) native bash support
5) sexier than MBP :P
I really like SP4 over MBP but I'm worried about its durability and service(in India).
What are your thoughts on this guyz?38 -
When you're developing it's very well advised to run your software locally in an environment as much as possible matching the real environment.
So for example, if you're running linux on production then you also run it locally to run your code.
Here's where people need to shut the fuck up:
No, mac is not good for linux development. Not unless portability is already a concern that you have and even then it might be counter productive. So many times when people say this, portability isn't not a concern. What runs on servers is up to them.
If your servers are going to be centos, then you develop with centos. Not with debian, gentoo, ubuntu, maxosx, etc.
Even different linux distros are a headache for portability when it's just to support a few desktops for development so don't think that macosx is going to cut it. It might not be as radical a difference as between windows and linux traditionally is but it's still not good for "linux" development. I don't think people making that statement really know what linux is now how different distributions work.
What you use for your graphical operating system doesn't matter to much but when you run your code then there's a simple solution.
Another thing people need to shut up about. It's not docker, unless you're already in Linux where docker is one of many options such as chroot or lxc.
This question always comes up, how do you developer for linux in windows? No it's not docker it's virtual machine.
It's that simple. You download the ISO for the distro you want and then install it on a VM. What does docker for windows do? It runs a linux VM that runs docker.
This may come as a great shock to developers around the world but it is possible to run linux in a VM and then any linux application your want including docker.
Another option is to shove a box in the corner, install what you need on it, share the file system and have people use that to run their code. It really is that easy.6 -
"Bu...bu..but JAVA SWING and FX are PORTABLE!"
And electrolytes are what plants crave.
I swear half the people I argue with are dinks.
IF YOU HAVE PEOPLE YOU ARE RESPONSIBLE FOR YOU HAVE TO DO WORK PEOPLE WILL HIRE YOU FOR.
Under job listings for javafx: 2 listings within 200 miles of me.
Under job listings for C#/WPF: dozens and dozens of jobs.
Portability doesn't matter if you're broke.
My stomach owes no allegiance to "high fallutin" concepts such as openness, avoiding vendor lock in, or the high ideals of platform independence.
I'll take the microsoft gulag if it pays my bills.
I don't know whats so hard to grasp about this. Some people are completely divorced from reality.
Edit: Hello to all my peeps who I haven't talked with in a while. I hope everything is going swimmingly in your lives. May your beer forever be paid for by your employer and your code bug free!5 -
I really hate PHP frameworks.
I also often write my own frameworks but propriety. I have two decades experience doing without frameworks, writing frameworks and using frameworks.
Virtually every PHP framework I've ever used has causes more headaches than if I had simply written the code.
Let me give you an example. I want a tinyint in my database.
> Unknown column type "tinyint" requested.
Oh, doctrine doesn't support it and wont fix. Doctrine is a library that takes a perfectly good feature rich powerful enough database system and nerfs it to the capabilities of mysql 1.0.0 for portability and because the devs don't actually have the time to create a full ORM library. Sadly it's also the defacto for certain filthy disgusting frameworks whose name I shan't speak.
So I add my own type class. Annoying but what can you do.
I have to try to use it and to do so I have to register it in two places like this (pseudo)...
Types::add(Tinyint::class);
Doctrine::add(Tinyint::class);
Seems simply enough so I run it and see...
> Type tinyint already exists.
So I assume it's doing some magic loading it based on the directory and commend out the Type::add line to see.
> Type to be overwritten tinyint does not exist.
Are you fucking kidding me?
At this point I figure out it must be running twice. It's booting twice. Do I get a stack trace by default from a CLI command? Of course not because who would ever need that?
I take a quick look at parent::boot(). HttpKernel is the standard for Cli Commands?
I notice it has state, uses a protected booted property but I'm curious why it tries to boot so many times. I assume it's user error.
After some fiddling around I get a stack trace but only one boot. How is it possible?
It's not user error, the program flow of the framework is just sub par and it just calls boot all over the place.
I use the state variable and I have to do it in a weird way...
> $booted = $this->booted;parent::boot();if (!$booted) {doStuffOnceThatDependsOnParentBootage();}
A bit awkward but not life and death. I could probably just return but believe or not the parent is doing some crap if already booted. A common ugly practice but one that works is to usually call doSomething and have something only work around the state.
The thing is, doctrine does use TINYINT for bool and it gets all super confused now running commands like updates. It keeps trying to push changes when nothing changed. I'm building my own schema differential system for another project and it doesn't have these problems out of the box. It's not clever enough to handle ambiguous reverse mappings when single types are defined and it should be possible to match the right one or heck both are fine in this case. I'd expect ambiguity to be a problem with reverse engineer, not compare schema to an exact schema.
This is numpty country. Changing TINYINT UNSIGNED to TINYINT UNSIGNED. IT can't even compare two before and after strings.
There's a few other boots I could use but who cares. The internet seems to want to use that boot function. There's also init stages missing. Believe it or not there's a shutdown and reboot for the kernel. It might not be obvious but the Type::add line wants to go not in the boot method but in the top level scope along with the class definition. The top level scope is run only once.
I think people using OOP frameworks forget that there's a scope outside of the object in PHP. It's not ideal but does the trick given the functionality is confined to static only. The register command appears to have it's own check and noop or simply overwrite if the command is issued twice making things more confusing as it was working with register type before to merely alias a type to an existing type so that it could detect it from SQL when reverse engineering.
I start to wonder if I should just use columnDefinition.
It's this. Constantly on a daily basis using these pretentious stuck up frameworks and libraries.
It's not just the palava which in this case is relatively mild compared to some of the headaches that arise. It's that if you use a framework you expect basic things out of the box like oh I don't know support for the byte/char/tinyint/int8 type and a differential command that's able to compare two strings to see if they're different.
Some people might say you're using it wrong. There is such a thing as a learning curve and this one goes down, learning all the things it can't do. It's cripplesauce.12 -
markdown is not good enough! the tools aren't there for non-devs and there's no concordance on moving forward *compatibly* for anything other than headers and __possibly__ lists.
md has been around for years and still no consensus on comments, meta data, css, data imports, etc.
i could never in good faith recommend to a non-dev to use markdown, even though every academic and professional writer from legal to journalism should exclusively be using markdown to write and store their documents. the data portability and ease of search, retrieval, collection, distribution, etc of markdown compared to pdf or docx is enormous. markdown is the hex format of text, the perfect layer of data and visual so that the user and the computer can both operate on text as blocks of data rather than weirdly styled paragraphs that need to be reformatted BY HAND for citation-style or journal format, or paper size. FOR EACH SUBMISSION. Academics literally rewrite their 100-page papers to accommodate up to 10 different submission requirements.
They could be clicking MLA vs Chicago and/or using a journal's stylesheet to recompile for its styles.
Today there is some support from zotero et al to take away some of the pain, but it makes ZERO SENSE for writers to have to keep and store and keep up to date, multiple versions of the same document. Git pull does not exist for them. But the worst part is that git isnt the solution to their problem. They need a compiler more than they need version control. But they also desperately need vcs. They ALL literally have a million files named "dumdum.dumFINAL-3084_lastversion \2020, this one.dum".
They dont have git or anything like it, because they need a line-by-line solution like markdown for git to become effective.
All of writing is basically mired in the fact that people cant even roll up their paragraphs and see what the fuck it is theyre saying. Most writing reads like a long scroll through some nonsense that goes nowhere. Like this rant. but the point is that markdown and line-by line editing actually produces more logically sound writing. You start to think in terms of defining ideas in blocks, ... like code.9 -
Random thoughts on more out of the box tools/environments.
Subject: Pharo
Some time ago I had shown one of my coworkers about Pharo and he quickly got the main idea behind it but mentioned how he didn't like the idea of leaving behind his text editor to deal with source code.
Some time last week I showed the dude some cool 3d animations you can do with Pharo while simultaneously manipulating the code to change them in real time. Now that caught his attention particularly and he decided he wanted to know more about the language but in particular the benefits of fucking around with an image based environment rather than a file based.
Both of us reached the conclusion that image based makes file based dev enviroments seem quaint in comparison, but estimated that it was nothing more than a sentiment rather than a fact.
We then considered what could be the advantage/disadvantages of such environments but I couldn't come up with anything other than the system not having something like Vim or VS Code or whatever which people love, but that it makes up for it with some of the craziest IDE tools I had ever seen. Plugins in this case act like source code repos that you can download and activate into your workflow in what feels something similar to VS Code being extended via plugins written in JS, and since the GUI is maleable as it is(because everything is basically just subsets of morp h windows) then extending functionality becomes so intuitive that its funny
Whereas with Emacs(for example) you have to really grind your gears with Elisp or Vimscript in Vim etc etc, with Pharo your plugin system is basicall you just adding classes that will convert your OS looking IDE into something else.
Because of how light the vm machine is, portability is a non issue, and passing pharo programs arround is not like installing Java in which you need the JVM.
Source code versioning, very important, already integrated into every live environment and can be extended to do pushes through simple key bindings with no hassle.
I dunno, I just feel that the tool is too good to be true. I keep trying to push limits into it but thus far I have found: data visualization and image modeling to work fine, web development with Teapot to be a cakewalk and work fine, therr are even packages for Arduino development.
I think its biggest con would be the image based system, but would really need to look into how this is bad by any reason other than "aww man I want vim!" since apparently some psychos already made Emacs and VS code packages for interfacing with Pharo source trees.
Embedded is certainly out of the question for any real project since its garbage collected and not the most performant cookie in the jar.
For Data science I can see some future, seems just as intuitive and interesting as a Jupyter Notebook actually, but the process can't and will not be the same since I still don't know of a way to save playground snippets unless you literally create classes for it, in which case every model you build gets saved inside of an object, sounds possible but, strange since it is not a the most common workflow in jupyter.
Some of the environment is sometimes glitchy, but it does have continuos development and have not found many hassles.
There is a biased factor from my side: I seem to be wired to understand the syntax and simple object model better than in other languages. To me this feels natural as if I was just writing ideas rather than code, mostly because I feel that there really ain't much in terms of syntax, the language gets out of my way and the IDE feels like the most intuitive environment in the world to me. I can see why some people would find it REALLY weird of counterintuitive tho.
Guess I really am a simple dude. -
One of our testers got the brilliant idea of switching the desktop environment to KDE on some debian. Response of our Qt-application: crash! - "Cannot mix incompatible Qt library"
Yeah. And we only want to support five distros in at least three different versions.