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
-
Remember the Ububtu mobile OS ?
I remember working on the community UI drive for this project. To know that something as awesome as ubuntu would come down into the form factor of a phone , was just ecstatic.
The first build was out , people liked it. People nagged a bit about the performance issues , but it was going fine. Then the second build .. then the third no one heard about and the 4th that never came.
The interface for this system was unique because after Wondows , this is the only other OS developer that embraced the one ecosystem mantra of design.
Using Ubuntu phone was natural , it was a small desktop OS.
I remember logging on to launchpad one day and seeing the Ubuntu mobile channel with it's last post " Thank you and goodbye "
It was heartbreaking , but i could understand. Like windows phone ( which if you guys weren't aware of , had APK support by the end of its lifecycle ) felt crushed under the weight of android and iOS.
Waiting for a day when there will be a third champion in game. I miss having to see Ubuntu being on my phone , but they seem to be doing great in everything else , so good on that. 😄
Ok done .. thanks
30 -
devRant is awesome, but Disney also manages to light-up my day.
This is how Wall-E became a beloved member of our team, and helped me put a smile on my face throughout a very frustrating project.
It all started in a company, not so far far away from here, where management decided to open up development to a wider audience in the organization. Instead of continuing the good-old ping-pong between Business and IT...
'not meeting my expectations' - 'not stated in project requirements'
'stuff's not working - 'business is constantly misusing'
'why are they so difficult' - 'why don't they know what they really want'
'Ping, pong, plok... (business loses point) ping, pong'
... the company aimed to increase collaboration between the 2 worlds, and make development more agile.
The close collaboration on development projects is a journey of falling and getting back up again. Which can be energy draining, but to be honest there is also a lot of positive exposure to our team now.
The relevant part for this story is that de incentive of business teams throughout these projects was mainly to deliver 'something' that 'worked'. Where our team was also very keen on delivering functionality that is stable, scalable, properly documented etc. etc.
We managed to get the fundamentals in place, but because the whole idea was to be more agile or less strict throughout the process, we could not safeguard all best-practices were adhered to during each phase of a project. The ratio Business/IT was simply out of balance to control everything, and the whole idea was to go for a shorter development lifecycle.
One thing for sure, we went a lot faster from design through development to deployment, high-fives followed and everybody was happy (for some time).
Well almost everybody, because we knew our responsibility would not end after the collection of credits at deployment, but that an ongoing cycle of maintenance would follow. As expected, after the celebrations also complaints, new requirements and support requests on bug fixes were incoming.
Not too enthusiastic about constantly patching these projects, I proposed to halt new development and to initiate a proper cleaning of all these projects. With the image in mind of a small enthusiastic fellow, dedicated to clean a garbage-strewn wasteland for humanity, I deemed "Wall-E" a very suited project name. With Wall-E on board, focus for the next period was on completely restructuring these projects to make sure all could be properly maintained for the future.
I knew I was in for some support, so I fetched some cool wall papers to kick-start each day with a fresh set of Wall-E's on my monitors. Subsequently I created a Project Wall-E status report, included Wall-E in team-meetings and before I knew it Wall-E was the most frequently mentioned member of the team. I could not stop to chuckle when mails started to fly on whether "Wall-E completed project A" or if we could discuss "Wall-E's status next report-out". I am really happy we put in the effort with the whole team to properly deploy all functionality. Not only the project became a success, also the idea of associating frustrating activities with a beloved digital buddy landed well in our company. A colleagues already kickstarted 'project Doraemon', which is triggering a lot of fun content. Hope it may give you some inspiration, or at least motivate you to watch Wall-E!
PS: I have been enjoying the posts, valuable learnings and fun experiences for some time now. Decided to also share a bit from my side, here goes my first rant!
3 -
Jesus titty fucking Christ people are stupid. I hate everyone in the software development lifecycle that isn’t a developer or isn’t technically minded. Everyone else seems to be a fucking goofy arse mother fucker.
I just got in trouble because I fixed a defect that never should have been fixed, even though in yesterdays standup they brought it up and asked me what the status of it was. Apparently I was just supposed to estimate the defect and see how long it would take to fix. Why the fuck wouldn’t we do that in a grooming session or a sprint planning session, you are just begging to confuse the devs. Absolute mud sharks.8 -
Just did my first JobIntentService on Android. Hoo, boy.
The problem: I need to send a network request.
The issue: Android.
Of course, you can't do network on the main thread. That's silly in any application. Android really does try to punish you, though. The Android lifecycle can really fuck you over here. Imagine a long-running network operation, like 15 seconds. Plenty of time for the user to do something silly, like rotate the screen.
If you opened up a good old new Thread from Java, you'd get a crash because of a screen rotation. Same thing with Android's AsyncTask, which is the top answer on StackOverflow. AsyncTask is made for things that will take no longer than a few seconds (less than 5!). Network, especially cell network, can take longer.
So the solution? Create a JobIntentService class. It's a service, it will run in the background. You need to register it in your Android Manifest and ask for a new permission (wake lock). You need to implement another class for the receiver, and then you need to go to your activity and implement the receiver interface you just wrote.
Just. For. A. Network. Request!
And as far as I'm aware, this isn't even that bad considering the rest of Android's bullshit.
What a headache!8 -
My job in a nutshell:
*fixes app, so it's working 99% bug free*
*Chrome update*
*app is full of bugs*
*fixes bugs*
*iOS 10 comes out*
*app is full of bugs*
*fixes bugs*
"we can now remove iOS7 support"
*removes code*
*app is full of bugs*
For fucks sake!!2 -
Last week's Android development time breakdown:
21.9% Managing state
17.7% Referring to lifecycle diagrams
15.1% Waiting for Gradle
8.5% Reading the official docs on how to use component x
8.4% Reordering auto-generated ConstraintLayout XML
7.5% Swearing
4.2% Googling “Stack overflow component x is deprecated”
3.9% Googling “Stack overflow implement component x on API 24 or lower”
3.7% Googling “Stack overflow implement component x on API 21 or lower”
3.2% Googling “Stack overflow implement component x on API 19 or lower”
2.9% Googling “Stack overflow callback y called twice”, realising its a feature and not a bug, swearing a lot
2.0% Checking if Flutter is mature yet
1.0% Implementing business logic4 -
Sorry to keep whining about my stupid fucking job, but y'all, I think I'm nearing my limit.
There's some good...I am pretty much free to resolve issues any way I want to, as the only other person in the company who "codes" only knows one old ass language that doesn't apply to 90% of the rest of the tech stack at all, and some SQL - all of that to say, we may disagree, but ultimately, these matters are always deferred to me at the end of the day, insofar as the actual implementation goes (which is to say I am not micromanaged). At least as far as non-visuals are concerned, because those of course, are the most important things. Button colors and shit, woo hoo**. That's what we should focus on as we're bringing in potentially millions of dollars per month - the god damn button color and collapsible accordions based on data type over the shit ass DB performance bottleneck, the lack of redundancy or backups (aside from the one I made soon after I started -- literally saved everyone today because of that. My thanks? None, and more bullshit tasks) or the 300GB+ spaghetti code nightmare that is the literal circulatory system of the FUCKING COMPANY. Hundreds of people depend on it for their livelihoods, and those of their families, but fuck me in the face, right? I'm just a god damn nerd who has worked for the federal government, a handful of fortune 500's, a couple of fortune 100's, some startups, etc. But the fuck do I know about the lifecycle of companies?
I could continue ranting, but what's the point? I've got a nice little adage that I've started to live by, and y'all might appreciate it: "If everything is a priority/is important, nothing is". These folks just don't fucking get it. I'm torn because, on the one hand, they waste my time and kinda underpay me, in addition to forcing me to be onsite for 50 hours a week. They don't listen to me, couldn't give a flying shit about my experientially based opinions. I'm just a fucking chimp with a typewriter, there to take commands like a fucking waiter. But there's a lot of job security, assuming I don't fucking snap one day, and the job market for devs (I'm sure I don't need to tell you) is hostile atm. I'm also drinking far more than usual, and I really need to do something about that. It's only wednesday - I think...not 100% on that truth be told, and I logged my fourth trip to the liquor store this week already.
**Dear backenders - don't ever learn front end, or if you do, just lie about it to avoid being designated full stack. It's not worth it.5 -
Android dev job question:
"Describe the activity lifecycle and write an application that does x,y,z in accordance with it"
Fullstack dev job question:
"Write some code that interacts with our API and does x,y,z, put the data into our database and build a web interface"
Java backend dev interview :
"BUILD AN ELEVATOR ALGORITHM WITH LESS THAN o(nlog(n)), FIND NEIGHBORS IN A BINARY TREE, WHAT IS THE DIFFERENCE BETWEEN AN INTERFACE AND ABSTRACT CLASS?"
Why?5 -
developer makes a "missed-a-semicolon"-kind of mistake that brings your non-production infrastructure down.
manager goes crazy. rallies the whole team into a meeting to find "whom to hold accountable for this stupid mistake" ( read : whom should I blame? ).
spend 1-hour to investigate the problem. send out another developer to fix the problem.
... continue digging ...
( with every step in the software development lifecycle handbook; the only step missing was to pull the handbook itself out )
finds that the developer followed the development process well ( no hoops jumped ).
the error was missed during the code review because the reviewer didn't actually "review" the code, but reported that they had "reviewed and merged" the code
get asked why we're all spending time trying to fix a problem that occurred in a non-production environment. apparently, now it is about figuring out the root cause so that it doesn't happen in production.
we're ALL now staring at the SAME pull request. now the manager is suddenly more mad because the developer used brackets to indicate the pseudo-path where the change occurred.
"WHY WOULD YOU WASTE 30-SECONDS PUTTING ALL THOSE BRACES? YOU'RE ALREADY ON A BRANCH!"
PS : the reason I didn't quote any of the manager's words until the end was because they were screaming all along, so, I'd have to type in ALL CAPS-case. I'm a CAPS-case-hater by-default ( except for the singular use of "I" ( eye; indicating myself ) )
WTF? I mean, walk your temper off first ( I don't mean literally, right now; for now, consider it a figure of speech. I wish I could ask you to do it literally; but no, I'm not that much of a sadist just yet ). Then come back and decide what you actually want to be pissed about. Then think more; about whether you want to kill everyone else's productivity by rallying the entire team ( OK, I'm exaggerating, it's a small team of 4 people; excluding the manager ) to look at an issue that happened in a non-production environment.
At the end of the week, you're still going to come back and say we're behind schedule because we didn't get any work done.
Well, here's 4 hours of our time consumed away by you.
This manager also has a habit of saying, "getting on X's case". Even if it is a discussion ( and not a debate ). What is that supposed to mean? Did X commit such a grave crime that they need to be condemned to hell?
I miss my old organization where there was a strict no-blame policy. Their strategy was, "OK, we have an issue, let's fix it and move on."
I've gotten involved ( not caused it ) in even bigger issues ( like an almost-data-breach ) and nobody ever pointed a finger at another person.
Even though we all knew who caused the issue. Some even went beyond and defended the person. Like, "Them. No, that's not possible. They won't do such dumb mistakes. They're very thorough with their work."
No one even talked about the person behind their back either ( at least I wasn't involved in any such conversation ). Even later, after the whole issue had settled down. I don't think people brought it up later either ( though it was kind of a hush-hush need-to-know event )
Now I realize the other unsaid-advantage of the no-blame policy. You don't lose 4 hours of your so-called "quarantine productivity". We're already short on productivity. Please don't add anymore. 🙏11 -
I guess this is the devRant update Birthday edition! It's my birthday and unfortunately I have to spend it at work. Luckily, I have devRant to keep me from being bored to tears.5
-
Software development lifecycle:
Step 1: Take shortcuts to get the project done in time.
Step 2: Wait for shit to hit the you know what
Step 3: Goto Step 14 -
We use at our company one of the largest Python ORM and dont code ourselfs on it, event tough I can code. Its some special contract which our General Manager made, before we as Devs where in the Project and everything is provided from the external Company as Service. The Servers are in our own Datacenter, but we dont have access.
We have our Consultants (Project Manager) as payd hires and they got their own Devs.
Im in lead of Code Reviews and Interfaces. Also Im in the "Run" Team, which observes, debuggs and keeps the System alive as 3rd-Level (Application Managers).
What Im trying to achieve is going away from legacy .csv/sftp connections to RestAPI and on large Datasets GraphQL. Before I was on the Project, they build really crappy Interfaces.
Before I joined the Project in my Company, I was a Dev for a couple of Finance Applications and Webservices, where I also did coding on Business critical Applications with high demand Scaling.
So forth, I was moved by my Boss over to the Project because it wasn't doing so well and they needed our own Devs on it.
Alot of Issues/Mistakes I identified in the Software:
- Lots of Code Bugs
- Missing Process Logic
- No Lifecycle
- Very fast growing Database
- A lot of Bad Practices
Since my switch I fixed alot of bugs, was the man of the hour for fixing major Incidents and so on so forth. A lot of improvements have been made. Also the Team Spirit of 15+ People inside the Project became better, because they could consult me for solutions/problems.
But damn I hate our Consultants. We pay them and I need to sketch the concepts, they are to dumb for it. They dont understand Rest or APIs in general, I need to teach them alot about Best Practices and how to Code an API. Then they question everything and bring out a crooked flawed prototype back to me.
WE F* PAY THEM FOR BULLCRAP! THEY DONT EVEN WRITE DOCUMENTATION, THEY ARE SO LAZY!
I even had a Meeting with the main Consultant about Performance Problems and how we should approach it from a technical side and Process side. The Software is Core Business relevant and its running over 3 Years. He just argumented around the Problem and didnt provide solutions.
I confronted our General Manager a couple of times with this, but since 3 Years its going on and on.
Im happy with my Team and Boss, they have my back and I love my Job, but dealing with these Nutjobs of Consultants is draining my nerves/energy.
Im really am at my wits end how to deal with this anymore? Been pulling trough since 1 year. I wanna stay at my company because everything else besides the Nutjob Consultants is great.
I told my Boss about it a couple of times and she agrees with me, but the General Manager doesnt let go of these Consultants.
Even when they fuck up hard and crash production, they fucking Bill us... It's their fault :(3 -
ColdFusion and all ColdFusion devs should be executed. Its a god-awful software from the 90's and if you still use it you're either braindead or ignorant.
Shut up about legacy CF code too! No one cares whether or not your embeddable calendar would be hard to make in JS; fucking figure it out.
I realise that CF may make things easier in the short run, but in the long run you'll have introduced so much technical debt that you'll run crying back to JS anyways; CF is so hard to refactor and even to make flexible that you would spend less total time over an application lifecycle learning JS.11 -
To me this is one of the most interesting topics. I always dream about creating the perfect programming class (not aimed at absolute beginners though, in the end there should be some usable software artifact), because I had to teach myself at least half of the skills I need everyday.
The goal of the class, which has at least to be a semester long, is to be able to create industry-ready software projects with a distributed architecture (i.e. client-server).
The important thing is to have a central theme over the whole class. Which means you should go through the software lifecycle at least once.
Let's say the class consists of 10 Units à ~3 hours (with breaks ofc) and takes place once a week, because that is the absolute minimum time to enable the students to do their homework.
1. Project setup, explanation of the whole toolchain. Init repositories, create SSH keys for github/bitbucket, git crash course (provide a cheat sheet).
Create a hello world web app with $framework. Run the web server, let the students poke around with it. Let them push their projects to their repositories.
The remainder of the lesson is for Q&A, technical problems and so on.
Homework: Read the docs of $framework. Do some commits, just alter the HTML & CSS a bit, give them your personal touch.
For the homework, provide a $chat channel/forum/mailing list or whatever for questions where not only the the teacher should help, but also the students help each other.
2. Setup of CI/Build automation. This is one of the hardest parts for the teacher/uni because the university must provide the necessary hardware for it, which costs money. But the students faces when they see that a push to master automatically triggers a build and deploys it to the right place where they can reach it from the web is priceless.
This is one recurring point over the whole course, as there will be more software artifacts beside the web app, which need to be added to the build process. I do not want to go deeper here, whether you use Jenkins, or Travis or whatev and Ansible or Puppet or whatev for automation. You probably have some docker container set up for this, because this is a very tedious task for initial setup, probably way out of proportion. But in the end there needs to be a running web service for every student which they can reach over a personal URL. Depending on the students interest on the topic it may be also better to setup this already before the first class starts and only introduce them to all the concepts in a theory block and do some more coding in the second half.
Homework: Use $framework to extend your web app. Make it a bit more user interactive with buttons, forms or the like. As we still have no backend here, you can output to alert or something.
3. Create a minimal backend with $backendFramework. Only to have something which speaks with the frontend so you can create API calls going back and forth. Also create a DB, relational or not. Discuss DB schema/model and answer student questions.
Homework: Create a form which gets transformed into JSON and sent to the backend, backend stores the user information in the DB and should also provide a query to view the entry.
4. Introduce mobile apps. As it would probably too much to introduce them both to iOS and Android, something like React Native (or whatever the most popular platform-agnostic framework is then) may come in handy. Do the same as with the minimal web app and add the build artifacts to CI. Also talk about getting software to the app/play store (a common question) and signing apps.
Homework: Use the view API call from the backend to show the data on the mobile. Play around with the mobile project to display it in a nice way.
5. Introduction to refactoring (yes, really), if we are really talking about JS here, mention things like typescript, flow, elm, reason and everything with types which compiles to JS. Types make it so much easier to refactor growing codebases and imho everybody should use it.
Flowtype would make it probably easier to get gradually introduced in the already existing codebase (and it plays nice with react native) but I want to be abstract here, so that is just a suggestion (and 100% typed languages such as ELM or Reason have so much nicer errors).
Also discuss other helpful tools like linters, formatters.
Homework: Introduce types to all your API calls and some important functions.
6. Introduction to (unit) tests. Similar as above.
Homework: Write a unit test for your form.
(TBC)4 -
!!metarant
Every time I write a rant or a comment from my phone, and I want to temporarily switch to another app to search or copy something, it's a fucking Russian roulette.
Will there be enough RAM, or will Android stop devRant thus losing all my content forever? Let's find out! The gun is loaded.
(What about handling the full activity lifecycle like Android requires?)
Now, I would like to attach a picture of the feared "task switch button", but I'm too afraid to lose everything, so fuck it3 -
Junior Software Developer Job( $37k-$42k USD)
-1 year experience
- J2EE, Javascript, HTML, XML, SQL
- object oriented design and implementation
- management of relational and non-relational such as Oracle, PostGreSQL and Cassandra
- Lifecycle and Agile methods
- Familiarity with the Eclipse development environment and with tools such as Hibernate, JMS, ,TomCat/Gemini/Jetty, OSGi.
• UNIX skills, including Bash or other scripting language
• Experience installing and configuring software packages
• ActiveMQ troubleshooting/knowledge
• Experience in scientific data processing and analytical science in general
• Automated testing tools and procedures, including JUnit testing, Selenium, etc.
• Experience in interfacing with scientific instrumentation, potentially over IP networks
• Familiarity with modern web development, user interface and other ever-evolving front-end
technologies, such as React, TypeScript, Material, Jest, etc.
I am betting they don't get many people applying.8 -
after exploring a lot of ui frameworks and architectures, i am trying to go back to android dev but again with the curiosity for the one single question that i had at the start of my career 5 years back : why is it's ui so complex?
can anyone help me understand it?
like comparing with the most basic ui framework : html/css/js, why android is so different? we got activities, fragments and views. the worst thing in android is lifecycles, that each of these ui components have.
The view lifecycle is simple to get over with : whatever is the lifecycle of its parent, is the lifecycle of view.
a view's parent is another view, whose parent is another view, whose parent is... and so on until we reach the root view which is stored by either a fragment or activity
therefore a view's lifecycle = lifecycle of activity or fragment
till here its very clear. the fuckup is simply in the next part:
WTAF is activity ?WTAF is fragment? why are their various functions called in the sequence they are called? oncreate, on start, onstartview, ondestroy... why?
activity is still somewhat okay, but fragment is completey weird af : it can be a part of activity: basically it can cover your complete screen and behave as an activity itself (so you don't get to say that activity === screen and fragment === view) AND IT HAS ITS OWN FUCKING LIFECYCLES! So does that mean fragment's fucntions cna also be called by OS?
what's more mind fucking, is the fact that android activity can destroy/pause or recreate fragments on its own, by some "views" like viewpager , or even hold multiple fragments as "alive" at the same time, using something called a "backstack" ??!??!
and each of these fragments in the stack can be called by system at any time? like wtf???
all these stuff is super confusing and i haven't even scratched the surface. the newer , more complicated stuff like viewmodel, livedata and again "lifecycles" has a complete seperate behavior and functionality of their own. plus the various "reality-check" scenarios like: when a user is streaming a video in picture-in-picture mode while keeping your app in split screen with maps in the second split, when a call comes and the video keeps running, and user rotates the device, let me know the clusterfuck situation for the 3rd fragment in your 5 icon navigation view currently at the payment page with 2 fragments and 1 activity in backstack!!!
god bless thy soul for this shitty framework isn't going anywhere , rather its super strong and getting more clusterfucked with new beautiful shit everyday.
(if someone can ignore my gentle language, i would really like to know/get redirected to some resources where i can learn more on this)3 -
ASP.NET Web Forns?
Can't tell how many times I printed out the page lifecycle diagram for myself or a coworker. So many hours lost trying to figure out which lifecycle hook to use for a specific scenario and then have it all break down because something new was added to the feature. Or figuring when data can be bound, or doing some hack because things break when handling a POST event or some shit.
Overly abstract piece of technological excrement. Might as well express the thing in contemporary dance and check that into source control instead of that ungodly mess.
The switch to AJAX and API calls was such a huge relief it's almost hard to explain in words (I can do a dance tho). And then upgrading to AngularJS, man, worlds apart...
I don't care how much they pay me (okay, you got me...), I'm never touching Web Forms again. -
* Create S3 Bucket
* Enable versioning
* Setup lifecycle to delete small temporary objects after 7 days
* Wait 7 years
* Say "Wow, I was fucking stupid, and I've learned a lot since then."
* Write devRant post
* Profit with lower monthly AWS bill1 -
Promotion - the slowest phase in the development lifecycle. Sometimes it never happens and is left forgotten in the dark.
-
i have a question for you. You work for an industry, a factory, in house. You have only one developer to help you.
They ask you for an app to store production and get reports. Ok
Then before a year passed, they want you to start making apps for: project managment, hr 360 evaluation, implementation of SSO without paying a third party service (like auth0 or okta)
Would you feel comfortable, even if the proper time was given, to get involved with so many different domains without anyone above you having any idea about software lifecycle and development?4 -
I love it when you and the dev team completely forget about the timeline and start implementing random shit thinking it'll work.
We will get there eventually -
We are awesome in creating incredible things but totally suck in maintaining or discard them properly.
-
I am having an introspective moment as a junior dev.
I am working in my 3rd company now and have spent the avg amount of time i would spent in a company ( 1- 1.5 years)
I find myself in similar problems and trajectories:
1. The companies i worked for were startups of various scales : an edtech platform, an insurance company (branch of an mnc) and a b2b analytics company
2. These people hire developers based on domain knowledge and not innovative thinking , and expect them to build anything that the PMs deem as growth/engagement worthy ( For eg, i am bad at those memory time optimising programming/ ds/algo, but i can make any kind of android screen/component, so me and people like me get hired here)
3. These people hire new PMs based on expertise in revenue generation and again , not on the basis of innovative thinking, coz most of the time these folks make tickets to experiment with buttons and text colors to increase engagement/growth
4. The system goes into chaos mode soon since their are so many cross operating teams and the PMs running around trying to boss every dev , qa and designer to add their changes in the app.
5. meanwhile due to multiple different teams working on different aspects, their is no common data center with up to date info of all flows, products and features. the product soon becomes a Frankenstein monster.
6. Thus these companies require more and more devs and QAs which are cogs in the system then innovative thinkers . the cogs in the system will simply come, dimwittingly add whatever feature is needed and goto home.
7. the cogs in system which also start taking the pain of tracking the changes and learning about the product itself becomes "load bearing cogs" : i.e the devs with so much knowledge of the product that they can be helpful in every aspect of feature lifecycle .
8. such devs find themselves in no need for proving themselves , in no need for doing innovative work and are simply promoted based on their domain knowledge and impact.
My question is simply this : are we as a dev just destined to be load bearing cogs?
we are doing the work which ideally a manager should be doing, ie maintaining confluence docs with end to end technical as well as business logic info of every feature/flow.
So is that the only definition of a Software Engineer in a technical product?
then how come innovations happen in companies like meta Microsoft google open ai etc?
if i have to guess as a far observer, i would say their diversity in different fields helps them mix and match stuff and lead to innovative stuff.
For eg, the android os team in google has helped add many innovative things in google cloud product and vice versa.
same is with azure and windows . windows is now optomissed to run in cloud machines when at one point it was just a horrible memory hogging and slow pc OS
for small companies, 1 ideology/product/domain is their hero ideology/product/domain .
an insurance company tries to experiment with stuff related to insurances,health,vehicles,and the best innovations they come up with is "lets give user a discount in premium if they do 5000 steps a day for an year".
edtech would say "lets do live streaming for children apart from static videos"
but Android team at google said , "since ai team is doing so well, lets include ai in various system apps and support device level models" ~ a much larger innovation as 2 domains combined to make a product
The small companies are not aiming to be an innovative product, they are just aiming to be a monopoly product. and this is kinda sad2 -
Dealing with React's setState and looking through all the possible lifecycle methods was so frustrating today.
It should have been a simple thing to disable a button, via the disabled prop, on click. I thought it would be enough to say
this.setState({ disableButton: true });
someSynchronousCode();
this.setState({ disableButton: false });
in the handler ... but it wasn't. The button would still be active for about a second after clicking. I tried several things like converting the synchronous code to a promise, trying componentDidUpdate with a comparison. It all failed. Interestingly enough removing the 2nd setState immediately disabled the button, though making it permanent.🙄
I've found a solution which seemed a bit hacky, changing the state back depending on another variable in the render method.
It seems so wrong, but it was the only solution I found after several hours.3 -
Spent the day figuring out how to maintain injected dependencies in scope when they're requested asynchronously later in the pipeline and then be able to clean it up later without having any lifecycle hooks to use.
Seriously considered switching DI frameworks before I just added an event when it's OK to dispose of the scope and I think it's finally working (without the memory leaks it had before).
Who else has to try something every possible way before you can be satisfied? -
Looks like @alice is an Authoring Lifecycle Collaboration Environment created by i4i
http://www.i4i.com/Alice.htm
1 -
Some of my first thoughts on the new 16.3 release of React...
New Context API:
- I’m glad they made the context API less scary, but as a redux user I will still be staying away from using context as a best practise.
Strict Mode:
- I like this a lot. React allows for great freedom in how you do things, but also offers the freedom to write some shit code that in the end does the job. A way to enforce best practises in JSX is good in my eyes.
New lifecycle methods:
- meh. Life moves on
https://medium.com/@baphemot/... -
Whyyyy whyyy can a billion dollar company be the last regarding Kubernetes as a service!! EKS has such a fat ass, damn slow to bootstrap and a pain to manage the lifecycle, while all other clouds even the small ones have figured it out. Can't just get it.6
Top Tags
Weekly Rant
View