Cloud-native developer. Distributed systems wannabe. DevOps and continuous delivery. 10x troublemaker. DevOps Manager at VHT.
7799 stories
·
1 follower

This Week in Numbers: Discrimination in the Tech Industry

1 Share

Regardless of their sex, one in three people would recommend an employer even if they had seen discrimination while working there. That is one takeaway from the Dice Diversity and Inclusion Report 2018. Based on a survey of US and UK tech professionals using Dice or and eFinancialCareers, the report looked at discrimination based on gender, age and politics.

The study found that 85 percent of women believe gender discrimination exists in the tech industry while only 62 percent of men feel likewise. In other words, twice as many many don’t see sexism. The results mirror many other studies that show men are much less likely to see sexism as a problem. This dynamic also plays out in regards to racism, with black and brown people much more likely to be concerned. Which leads us to ask, why wasn’t discrimination based on ethnicity discussed? The omission is striking!

Likely because of personal experiences with gender discrimination, only 59 percent of women are willing to recommend their employer as a place to work while 79 percent would do so. Digging deeper into the subject, many men would change their minds if they thought the employer was allowing discrimination to continue. In fact, almost the same percentage of women and men (33 percent and 44 percent respectively) would recommend their employer even if they have seen discrimination in that workplace. Stated another way, about a third of the tech community is willing to accept discrimination as a fact of life.

Tech Ageism

According to the Dice survey, more tech professionals experienced or witnessed discrimination due to age compared to gender, political affiliation, or sexual orientation. Although we know that many younger professionals participated in the survey, the exact proportion is unknown. If the sample over-represented older professionals, then ageism may not be as a significant problem as gender discrimination. Just don’t tell that to people over 40 — well over half of this group are concerned that their age is a barrier to them getting a new job. In fact, among those 55 or older, 88 percent are worried that their age can hurt their continuing career.

 

Almost nine out of ten 50+ year old respondents are worried about their age will be a barrier to getting a new job.

Feature image by Samantha Sophia on Unsplash.

The post This Week in Numbers: Discrimination in the Tech Industry appeared first on The New Stack.

Read the whole story
sbanwart
2 days ago
reply
Akron, OH
Share this story
Delete

This Week in Programming: Is Code Necessary to Coding?

1 Share

Some news everyone seems to be interested in this week is the general availability of Google’s “low-code environment App Maker,” which promises to make it “easy for your team to iterate from prototype to deployed app,” regardless of their lack of coding experience and formal training in the fine art of computer programming.

For most developers out there, I have to imagine that the reaction to this sort of news, as with most “low-code” solutions of the sort, falls somewhere between “good luck with that” and “thank goodness, now I don’t have to do it.” For me, whenever I see one of these new, low-code options, it makes me rethink what it really means to be a developer, coder, programmer, or whatever else we want to call ourselves.

I’m always brought back to those early days of manually copying BASIC code out of the back pages of Discovery magazine. That was the essence of learning to code. That and accidentally corrupting my boot sector by dabbling with assembly code, or destroying some essential data while learning to read and write to files, or whatever else. It involves some essential level of inaccessibility and difficulty — almost like a hazing. That was the cost of admittance to the high society of computer programmers.

Is any of that really necessary to be a developer, though? Or is it more simply a way of thinking?

All too often, these low-code offerings seem to offer the promise of easy app development to the unskilled, but I dare to say that the skill is not in knowing the code, but rather knowing HOW to program the computer – how to tell the computer what to do and interact with the human on the other end. Surely, there are deeper levels of coding and understanding (that far outpace my own meager understanding, as well), but even developing a simple “line-of-business” app, as the announcement calls it, takes more than a technical understanding of code. These days, I watch as my nine-year-old niece learns to “code” using MIT’s Scratch, and while she doesn’t have to struggle with these same terrible initiation rights, she is learning how to think through every step and possibility. She is learning to account for edge use cases and how one step leads to the next and how she can’t take anything for granted. The computer does exactly what she tells it to do, nothing more and nothing less. And anyone hoping to build an app for their business — no matter their knowledge or lack thereof of actual “code” — needs to embody exactly those skills.

Google even acknowledges this line of discernment in its introduction of App Maker:

Code does not make the coder, but rather the way of thinking. These low-code solutions are opening up the world of coding to people who won’t take the time to understand code, but will take the time to learn how to think like a coder. In the meantime, low-code seems to make life easier for those who already understand how to code, as well, which is… well… pretty awesome, if you ask me.

This Week in Programming

  • TypeScript Hits Its Stride: If the TIOBE Index is any indicator, TypeScript has finally hit its stride as it finally joined the TIOBE top 100. The TIOBE Index tracks language popularity and JAXEnter reports that “TypeScript finally debuts at #93,” remarking that “while many are vocal about their love for this MS language, it’s never been too popular across a widespread audience.” Read on for a look at the other movements in language popularity this time around, including a notable rise in the use of PHP and Visual Basic, of all things.
  • Fo Brings Functional Programming Features to Go: And another story from JAXEnter introduces us to Fo, an experimental superset for Go. According to the article, Functional Go, or Fo, has one feature so far — type polymorphism via generics. In essence, this feature makes “it possible to write flexible higher-order functions and type-agnostic data structures” and “gives us a glimpse into what Go would look like with some new language features and allows us to explore how those features interact and what you can build with them.” Really, Fo is just in its initial experimental phase, but it definitely caused a stir among the Go community this week, it would seem.
  • Facebook’s Sonar Goes Open Source: Next up, SDTimes reports that Facebook has open sourced Sonar, its extensible debugging tool that was “originally created to help Facebook engineers manage the complexity of working with multiple different modules.” According to Facebook’s announcement, Sonar provides “a highly flexible, intuitive way to inspect and understand the structure and behavior of their iOS and Android applications… by providing a more visual and interactive experience that is extensible to fit engineers’ specific needs.” The tool is now available on GitHub and Facebook offers a quick guide on how to implement Sonar plugins.
  • No More Third-Party Chrome Extension Installs: Google is putting the kibosh on third-party Chrome extension installs and Techcrunch explains to us why we can’t have nice things anymore. Essentially, up until this announcement, “developers who publish their apps in the Web Store could also initiate app and extension installs from their own websites,” which they did deceptively at times. Starting September 18, 2018, those inline installs will be no more, and Chrome users will instead be redirected to the Chrome Web Store instead to install the extension.
  • The Snapchat Snap Kit Rumors are True: Rumors were swirling that Snapchat was working on an SDK, and ProgrammableWeb reports that they are indeed true, as Snapchat Launches Snap Kit, calling it “a big announcement based on the company’s previously walled-off approach to third-party developers.” Snap Kit employes “a series of APIs to give developers access to Snapchat features within third-party apps” and includes four basic pieces: Creative Kit, Login Kit, Bitmoji Kit, and Story Kit. These kits give developers access to the Snapchat camera, the ability to login into third-party apps with Snapchat credentials, use Snapchat Bitmoji stickers within integrated apps, and embed Snapchat stories within third-party apps, respectively. Apply directly with Snapchat to request access.
  • Deploying Node.js to App Engine: Google announced this week that you can deploy your Node.js app to App Engine standard environment, which lets you “you deploy web and mobile applications without worrying about the underlying infrastructure” and enjoy “zero-config deployments, zero server management and auto-scaling capabilities.” Google also offers a quickstart guide on how to get started with Node.js on App Engine.

Google and Microsoft are sponsors of The New Stack.

Feature image via Pixabay.

The post This Week in Programming: Is Code Necessary to Coding? appeared first on The New Stack.

Read the whole story
sbanwart
2 days ago
reply
Akron, OH
Share this story
Delete

F# Weekly #24, 2018 – Fable Conf 2018, 26-27 October, Berlin!

2 Shares

Welcome to F# Weekly,

A roundup of F# content from this past week:

News

Videos & Slides

Blogs

F# vNext:

Open source projects

New Releases

That’s all for now. Have a great week.

Previous F# Weekly edition – #23, 2018Subscribe





Read the whole story
alvinashcraft
1 day ago
reply
West Grove, PA
sbanwart
2 days ago
reply
Akron, OH
Share this story
Delete

Penny Pinching in the Cloud: Deploying Containers cheaply to Azure

2 Shares

imageI saw a tweet from a person on Twitter who wanted to know the easiest and cheapest way to get an Web Application that's in a Docker Container up to Azure. There's a few ways and it depends on your use case.

Some apps aren't web apps at all, of course, and just start up in a stateless container, do some work, then exit. For a container like that, you'll want to use Azure Container Instances. I did a show and demo on this for Azure Friday.

Azure Container Instances

Using the latest Azure CLI  (command line interface - it works on any platform), I just do these commands to start up a container quickly. Billing is per-second. Shut it down and you stop paying. Get in, get out.

Tip: If you don't want to install anything, just go to https://shell.azure.com to get a bash shell and you can do these command there, even on a Chromebook.

I'll make a "resource group" (just a label to hold stuff, so I can delete it en masse later). Then "az container create" with the image. Note that that's a public image from Docker Hub, but I can also use a private Container Registry or a private one in Azure. More on that in a second.

Anyway, make a group (or use an existing one), create a container, and then either hit the IP I get back or I can query for (or guess) the full name. It's usually dns=name-label.location.azurecontainer.io.

> az group create --name someContainers --location westus

Location Name
---------- --------------
westus someContainers
> az container create --resource-group someContainers --name fancypantscontainer --image microsoft/aci-helloworl
d --dns-name-label fancy-container-demo --ports 80
Name ResourceGroup ProvisioningState Image IP:ports CPU/Memory OsType Location
------------------- --------------- ------------------- ------------------------ ---------------- --------------- -------- ----------
fancypantscontainer someContainers Pending microsoft/aci-helloworld 40.112.167.31:80 1.0 core/1.5 gb Linux westus
> az container show --resource-group someContainers --name fancypantscontainer --query "{FQDN:ipAddress.fqdn,ProvisioningState:provisioningState}" --out table
FQDN ProvisioningState
--------------------------------------------- -------------------
fancy-container-demo.westus.azurecontainer.io Succeeded

Boom, container in the cloud, visible externally (if I want) and per-second billing. Since I made and named a resource group, I can delete everything in that group (and stop billing) easily:

> az group delete -g someContainers 

This is cool because I can basically run Linux or Windows Containers in a "serverless" way. Meaning I don't have to think about VMs and I can get automatic, elastic scale if I like.

Azure Web Apps for Containers

ACI is great for lots of containers quickly, for bringing containers up and down, but I like my long-running web apps in Azure Web Apps for Containers. I run 19 Azure Web Apps today via things like Git/GitHub Deploy, publish from VS, or CI/CD from VSTS.

Azure Web Apps for Containers is the same idea, except I'm deploying containers directly. I can do a Single Container easily or use Docker Compose for multiple.

I wanted to show how easy it was to set this up so I did a video (cold, one take, no rehearsal, real accounts, real app) and put it on YouTube. It explains "How to Deploy Containers cheaply to Azure" in 21 minutes. It could have been shorter, but I also wanted to show how you can deploy from both Docker Hub (public) or from your own private Azure Container Registry.

I did all the work from the command line using Docker commands where I just pushed to my internal registry!

> docker login hanselregistry.azurecr.io

> docker build -t hanselregistry.azurecr.io/podcast .
> docker push hanselregistry.azurecr.io/podcast

Took minutes to get my podcast site running on Azure in Web Apps for Containers. And again - this is the penny pinching part - keep control of the App Service Plan (the VM underneath the App Service) and use the smallest one you can and pack the containers in tight.

Watch the video, and note when I get to the part where I add create an "App Service Plan." Again, that's the VM under a Web App/App Service. I have 19 smallish websites inside a Small (sometime a Medium, I can scale it whenever) App Service. You should be able to fit 3-4 decent sites in small ones depending on memory and CPU characteristics of the site.

Click Pricing Plan and you'll get here:

Recommend Pricing tiers have many choices

Be sure to explore the Dev/Test tab on the left as well. When you're making a non-container-based App Service you'll see F1 and D1 for Free and Shared. Both are fine for small websites, demos, hosting your github projects, etc.

Free, Shared, or Basic Infrastructure

If you back up and select Docker as the "OS"...

Windows, Linux, or Docker

Again check out Dev/Test for less demanding workloads and note B1 - Basic.

B1 is $32.74

The first B1 is free for 30 days! Good to kick the tires. Then as of the timing of this post it's US$32.74 (Check pricing for different regions and currencies) but has nearly 2 gigs of RAM. I can run several containers in there.

Just watch your memory and CPU and pack them in. Again, more money means better perf, but the original ask here was how to save money.

Low CPU and 40% memory

To sum up, ACI is great for per-second billing and spinning up n containers programmatically and getting out fast) and App Service for Containers is an easy way to deploy your Dockerized apps. Hope this helps.


Sponsor: Check out dotMemory Unit, a free unit testing framework for fighting all kinds of memory issues in your code. Extend your unit testing with the functionality of a memory profiler.



© 2018 Scott Hanselman. All rights reserved.
     
Read the whole story
alvinashcraft
2 days ago
reply
West Grove, PA
sbanwart
2 days ago
reply
Akron, OH
Share this story
Delete

Azure API Management roadmap is moving to Azure Roadmap

1 Share

Almost two years ago we launched the public Azure API Management roadmap.

The roadmap worked very well and allowed the team to share plans and collect valuable feedback and enabled customers to stay informed and connected to the team.

In the meantime, Microsoft launched the official Azure roadmap to enable all Azure services to share their plans consistently and efficiently.

So, today, with a touch of sadness, we announce the closure of the standalone Azure API Management roadmap. From now on we will use the official Azure roadmap for sharing near-term plans, work in progress, and completed items.

Each of the roadmap item will contain a link to a corresponding item on the Azure feedback forum, where you will be able to comment and vote on that feature. Azure feedback forum will also be the primary channel for general product ideas, feedback, and for sharing product plans.

Azure API Management team continues to believe in customer focus, transparency, and dialog and is committed to reviewing and responding to your comments on these channels diligently. Please keep your feedback coming!

Read the whole story
sbanwart
2 days ago
reply
Akron, OH
Share this story
Delete

Introducing Dask for Scalable Machine Learning

1 Share

Although Python contains several powerful libraries for machine learning, unfortunately, they don’t always scale well to large datasets. This has forced data scientists to use tools outside of the Python ecosystem (e.g., Spark) when they need to process data that can’t fit on a single machine. But thanks to Dask, data scientists can now use …
Read more →

The post Introducing Dask for Scalable Machine Learning appeared first on Anaconda.

Read the whole story
sbanwart
3 days ago
reply
Akron, OH
Share this story
Delete
Next Page of Stories